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I.  INTRODUCTION 


A.  PURPOSE 

This  thesis  formulates,  examines  and  illustrates  specific  principles  of 
acquisition  management  designed  to  increase  the  probability  of  successful 
acquisition  of  Defense-related  information  systems.  A  Tactical  Service  Oriented 
Architecture  (TSOA)  for  the  United  States  Marine  Corps  (USMC),  as  a  concept 
on  its  way  to  an  acquisition  program  of  record,  illustrates  the  principles  of  this 
management  strategy.  The  recommendations  conveyed  in  this  thesis  have 
applicability  to  not  only  the  acquisition  of  a  USMC  TSOA,  but  also  to  Department 
of  Defense  (DoD)  Information  Technology  (IT)  acquisition  in  general. 

B.  OBJECTIVES 

This  thesis  has  several  objectives.  Directly  related  to  the  stated  purpose 
above,  the  primary  objective  suggests  an  improved  approach  to  DoD  acquisition 
of  IT  systems,  using  value-based  logic  and  ready  for  immediate  implementation 
by  the  Services.  (Hereafter,  Services  with  a  capital  ‘S’  refers  to  the  branches  of 
U.S.  military  services  -  the  Army,  Navy,  Air  Force,  and  Marine  Corps  -  and  the 
U.S.  Coast  Guard.)  As  a  secondary  objective,  this  thesis  illustrates  the 
application  of  this  acquisition  approach  to  a  subject  of  direct  interest  to  the 
USMC:  Tactical  Service  Oriented  Architecture.  Additionally,  in  order  to  build 
foundational  background  and  support  for  the  primary  and  secondary  objectives 
above,  this  thesis  includes  an  analysis  of  DoD  IT  program  success  versus  failure. 

C.  RELEVANCE 

The  topic  of  an  improved  approach  for  the  acquisition  of  DoD  information 
systems  emerged  through  the  research  of  material  provided  by  the  Marine  Corps 
Systems  Command  in  Ouantico,  Virginia,  in  its  pursuit  of  expertise  on  Service 
Oriented  Architectures  (SOAs).  In  April  2008,  the  Marines  published  a  request 
for  information  (RFI)  that  solicited: 
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...ideas,  initiatives,  and/or  processes  [related  to  the]  governance, 
development,  and  operation  of  Service  Oriented  Architectures 
(SOA)  within  the  United  States  Marine  Corps  at  the  tactical  and 
enterprise  levels.  (FedBizOpps.gov,  2008) 

The  RFI  explains  that  the  solicitation  results  from  DoD  direction  (DoDD 
8320.02,  2004)  to  migrate  legacy  IT  architectures  to  SOAs  to  the  greatest  extent 
possible  and  to  the  lowest  level  tactically  possible.  Marine  Corps  leadership  is 
approaching  this  daunting  task  with  skeptical  apprehension  as  evident  in  the 
RFI’s  additional  statement,  “...if  not  implemented  correctly,  the  transition  to  a 
SOA  will  greatly  disrupt  operations  at  the  tactical  and  enterprise  level,  increase 
costs,  and  adversely  affect  combat  efficiency.” 

The  Marine  Corps  and  other  government  agencies  maintain  justifiable 
uneasiness  in  implementing  a  “solution”  that  will  have  effects — positive  or 
negative — across  the  board,  both  on  enterprise  and  edge  (tactical)  users.  Failure 
in  this  acquisition  endeavor  potentially  looms  in  the  distance,  and,  if  realized, 
failure  would  have  lasting  disruptive  consequences.  Improving  the  manner  in 
which  we,  the  DoD,  develop  and  procure  our  IT  systems,  will  reduce  the  chances 
of  such  failure.  Subsequent  chapters  reveal  sound  principles  for  DoD  IT 
acquisitions  that  accomplish  this  improvement. 

D.  THESIS  QUESTIONS 

This  thesis  focuses  on  IT  acquisition  management.  As  such,  it  aims  to 
answer  one  primary  question  involving  IT  acquisition  in  the  DoD  and  the  Marine 
Corps,  and  three  secondary  questions,  the  first  two  of  which  help  define  Defense 
acquisition  project  success.  The  last  secondary  question  relates  to  the 
acquisition  of  a  USMC  TSOA.  The  questions  posed  are: 

1.  Primary  Research  Question: 

a.  What  are  the  essential  principles  of  acquisition  to 

successfully  deliver  valued  capabilities  to  the  warfighter? 

2.  Secondary  Research  Questions: 

a.  What  defines  acquisition  project  success  and  failure,  and 
what  causes  one’s  failure? 
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b.  How  does  the  concept  of  timeliness  fit  in  the  equation  for 
acquisition  value? 

c.  How  can  the  USMC  apply  the  essential  principles  of  rapid, 
value-based,  evolutionary  acquisition  to  the  development 
and  procurement  of  a  TSOA? 
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II.  BACKGROUND 


A.  JUSTIFIABLE  APPREHENSION 

The  USMC,  DoD,  and  businesses  worldwide  are  approaching  IT  projects 
with  increasing  trepidation...  and  rightfully  so.  Failed  IT  acquisition  projects 
costing  investors  and  taxpayers  billions  of  dollars  annually  litter  the  path  to 
“improvement”  much  to  the  dismay  of  well-intended,  experienced  and 
knowledgeable  project  managers  and  executives.  According  to  a  2005  study, 
organizations  will  completely  abandon  5-15%  of  all  IT  projects  before  or  shortly 
after  delivery  (Charette,  2005).  These  numbers  appear  optimistic  when 
considering  another  2005  study,  which  states  that  only  10%  of  250  different 
projects  reviewed  successfully  achieved  their  stated  objectives  for  cost,  schedule 
and  quality  (Jones  C.  ,  2004).  While  the  other  90%  of  those  projects  did  not 
totally  fail,  a  startling  9  out  of  10  never  achieved  their  goals!  Yet  another 
interesting  generalization  says  25%  of  all  IT  projects  fail,  25%  succeed,  and  the 
other  50%  fall  somewhere  between  success  and  failure  (Kozak-Holland,  2007). 
These  statistics  vary,  but  they  all  grab  our  attention  because  of  the  staggering 
failure  rates.  Technology  professionals  in  the  public  and  private  sector  alike  fully 
recognize  these  facts  and  yet  the  struggles  continue  in  the  area  of  IT  project 
management  and  acquisition. 

The  Defense  Department  has  no  immunity  to  this  plague.  Nearly  all  major 
defense  acquisition  programs  today  include  a  significant  amount  of  software  and 
IT.  The  Marine’s  MV-22  Osprey  for  example  contains  over  10  million  lines  of 
code  and  the  Joint  Strike  Fighter  over  11  million.  Without  their  complex  suite  of 
computerized  flight  control  systems  which  significantly  rely  on  IT,  neither  would 
fly,  much  less  accomplish  their  stated  missions.  This  complexity  has  contributed 
to  schedule  delays,  cost  overruns,  or  even  program  cancellation  in  the  case  of 
the  Navy’s  A-12  carrier-based  attack  aircraft  (Stevenson,  2001).  Not  limited  to 
aviation,  these  problems  contributed  to  the  ineffectiveness  and  eventual 
cancellation  of  the  U.S.  Army’s  M247  Sergeant  York  anti-aircraft  gun  in  1985. 
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More  currently,  the  Army’s  highly  complex  Future  Combat  Systems  program  with 
its  estimated  32  million  lines  of  code  struggles  with  increasing  costs  and  lagging 
schedules.  These  types  of  delays,  overruns,  and  other  programmatic  problems 
combined  with  unsatisfactory  performance  or  flat-out  system  failures  have  led  the 
U.S.  Government  Accountability  Office  (GAO)  to  designate  the  DoD  systems 
development  and  modernization  efforts  as  a  “high-risk  area”  (GAO/HR-99-1, 
1999).  One  must  ask...  Why? 

B.  PROJECT  SUCCESS  AND  FAILURE  DEFINED 

Before  analyzing  the  causes  of  such  a  dismal  performance  record  for  IT 
acquisition,  the  context  of  this  thesis  requires  a  more  concise  definition  of  project 
success  and  failure  as  the  terms  apply  to  DoD  systems  acquisitions.  Without  a 
clear  understanding  of  the  meanings  of  the  words,  analysis  of  their  causes  and 
application  of  potential  solutions  stretches  to  impossibility.  After  solidifying  these 
definitions,  they  will  serve  as  reference  points  throughout  the  remainder  of  this 
thesis. 


1.  Part  of  the  Problem:  A  Lack  of  Definition  of  Success 

Lacking  a  distinct  definition  of  success  and  failure,  a  project  will  most  likely 
never  attain  and  avoid  each  respectively. 

The  big  problem  with  assessing  project  success  is  that  it  is  not 
precise...  This  dynamic  can  often  be  the  Achilles  heel  for  a  project. 
Without  a  dependable  understanding  of  what  constitutes  success, 
the  project  is  placed  in  the  untenable  position  of  being  judged 
against  differing  criteria,  and  invariably  becomes  one  more  failure 
statistic  reported  by  research  firms...  (O'Brochta,  2002) 

The  North  American  English  Encarta  Dictionary  characterizes  success  as  the 
achievement  of  something  planned  or  attempted.  But  what  exactly  defines  that 
“something”  for  an  IT  project? 
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IT  projects  typically  have  multiple  goals  and  objectives.  Which  one  or 
ones  really  count  hinges  on  opinion  and  varies  widely  depending  on  the  domain 
and  the  stakeholder’s  position  of  interest  within  or  relative  to  that  domain.  For 
instance,  a  performance  objective  of  an  IT  project  in  the  domain  of  a  private 
sector  business  may  include  streamlining  a  process  in  order  to  increase 
efficiency.  An  example  of  such  a  project  is  the  development  and  employment  of 
an  airline’s  self-check-in  system  intended  to  decrease  customer  wait  times  by  a 
certain  percentage.  This  same  project  most  likely  would  have  internal  cost  and 
schedule  goals  for  its  implementation  in  addition  to  its  performance  goals.  In  the 
end,  if  the  project  runs  a  bit  over  budget  and  begins  operation  a  few  weeks 
behind  schedule  but  still  meets  its  performance  objectives,  upper  level 
management  would  probably  categorize  it  as  a  success,  even  though  it  did  not 
meet  all  of  its  objectives.  (Note  the  project  manager  however,  as  a  different 
stakeholder  may  have  another  opinion  and  consider  it  a  personal  failure  since 
cost  and  schedule  goals,  as  his  responsibility,  missed  the  mark.)  Now 
considering  another  outcome,  if  it  met  its  budget  and  time  objectives  but  failed  to 
meet  its  performance  goal  to  decrease  customer  wait  times,  all  stakeholders 
would  probably  consider  it  a  failed  project.  Why?  Because  in  this  case  and 
others  in  the  private  sector,  the  reason  for  failure  classification  is  often  easy  to 
understand:  “Success  for  the  commercial  world  is  straightforward  and  simple: 
maximize  profit.”  (GAO-06-110,  2006)  Private  sector  businesses  conceive 
projects  in  order  to  improve  the  bottom  line,  through  either  cutting  costs  or 
increasing  revenue,  and  a  business  would  most  likely  not  consider  a  venture 
project  unless  it  has  the  potential  to  generate  positive  returns.1  In  our  example 
above,  the  likely  intent  of  the  airline  self-check-in  system  might  include  improving 
the  customers’  experience,  resulting  in  repeat  business,  which  would  in  turn 
increase  revenue.  Or  perhaps  the  company  intended  to  reduce  the  number  of 


1  This  is  an  intentional  oversimplification  and  not  intended  to  convey  that  all  businesses  are 
purely  self-promoting  entities  that  do  not  participate  in  other  worthwhile  activities  that  might  not 
necessarily  generate  profit.  Examples  of  these  activities  include  those  which  improve  public 
image,  improve  employee  health,  contribute  to  worthy  community  or  charitable  causes,  etc. 
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employees  behind  the  check-in  counter,  which  would  decrease  costs.  Either 
way,  both  of  these  desired  results  affect  the  company’s  financial  bottom  line, 
which  truly  determines  success  or  failure  upon  completion  of  a  commercial 
project. 

Unfortunately,  project  success  in  a  public  sector  organization  such  as  the 
Defense  Department  eludes  such  clear  definition,  and  this  fact  leads  to  problems. 
Taking  a  simplistic  view  when  comparing  DoD  to  commercial  systems 
acquisition,  success’s  definition  initially  appears  similar:  deliver  a  product  that 
meets  the  requirements,  on  time  and  for  the  right  price.  Further  investigation, 
however,  reveals  the  implied  definition  for  success  at  least  in  the  DoD 
complicates  the  matter.  Often  a  program’s  ability  to  attract  funds  for  itself  and 
other  projects  defines  success,  instead  of  the  program  meeting  any  real 
objectives.  Project  managers  on  both  the  government  and  defense  contractor 
sides  accomplish  this  through  overly  optimistic  cost  and  schedule  estimates  or  by 
avoiding  or  delaying  reports  of  bad  news  that  might  decrease  a  program’s 
funding  line  (GAO-06-110,  2006).  The  figure  below  shows  a  comparison  of 
commercial  project  success  versus  DoD  project  success  and  the  resulting 
behaviors  as  reported  by  the  GAO. 
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Commercial  companies 

DOD 

Success 

Sale  to  customer. 

Attracting  funds. 

Means  to 
success 

Strategic  planning/prioritizing. 

Competition  for  funds. 

Realism  and  candor. 

Optimism  and  unknowns. 

Early  testing. 

Late  testing. 

Early  redllghts,  greenllghts  based  on 
demonstration. 

Early  greenllghts;  late  redllghts. 

Collaboration  and  trust. 

Oversight  and  distrust. 

Senior  leaders  are  program 
advocates.  Corporate  research 
departments  are  technology 
developers.  Program  manager  Is 
executor. 

Program  manager  Is  often  the 
advocate,  technology  developer, 
and  executor. 

Single  program  manager  Is 
accountable  for  delivery. 

Multiple  program  managers  are 
accountable  tor  continuation. 

Source:  GAO. 


Figure  1.  Differences  in  Definition  of  Success  and  Resulting  Behaviors 

(From  GAO-06-110) 

According  to  the  Under  Secretary  of  Defense  for  Acquisition,  Technology 
and  Logistics,  "...  the  enterprise  will  often  pressure  acquisition  teams  and 
industry  to  provide  low,  optimistic  estimates  to  help  start  programs.”  (Young, 
2009)  These  overly  optimistic  cost,  schedule  and  performance  estimates 
ultimately  hurt  any  program  because  the  eventual  application  of  realistic 
estimates  reveal  a  program  unexpectedly  in  a  cost  overrun,  behind  schedule  and 
failing  to  meet  performance  objectives.  This  sometimes  occurs  when  a  program 
commences  its  critical  early  stages.  If  a  program  survives  such  a  disadvantaged 
initiation,  it  most  likely  will  produce  a  sub-par  performing  system  in  the  hands  of 
the  end  user  -  the  warfighter  in  tactical  domain  of  the  DoD.  Nevertheless,  was 
this  program  a  success?  Unlike  the  commercial  world,  a  simple  measurement  of 
profit  or  loss  does  not  answer  this  question.  Nor  does  the  ability  of  the  project  to 
“stay  alive”  and  continue  attracting  funding  support  determine  success.  Instead, 
value  delivered  to  the  customer  determines  the  true  success  or  failure  of  a 
tactical  DoD  system. 
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2.  DoD  Acquisition  Program  Success  vs.  Failure 

The  warfighter  who  ultimately  will  use  a  tactical  system  wants  that  system 
to  contribute  to  his  or  her  mission.  The  ability  of  that  system  to  contribute  value 
to  the  warfighter’s  task  defines  success  for  that  class  of  stakeholders.  Thus, 
value  delivered  by  that  system  equates  to  success.  The  system  can  contribute  in 
many  different  ways.  Perhaps  it  lightens  a  load,  improves  communications 
ability,  increases  decision-making  effectiveness,  or  improves  survivability.  Since 
the  warfighter  considers  value-adding  systems  or  products  successes,  one 
should,  by  the  same  token,  consider  the  projects  or  programs  which  developed 
and  procured  them  successful.  Similarly,  the  warfighter  also  determines  project 
failure.  If  a  fielded  system  improves  no  aspect  of  a  warfighter’s  job,  it  fails.  This 
judgment  of  failure  depends  not  on  coming  in  over  budget  or  behind  some 
arbitrary  programmatic  schedule.  Instead,  it  rests  on  the  system  not  satisfying 
user-defined  quality  attributes  on  the  user’s  timeline.  Simply  stated,  if  the  system 
does  not  provide  value  to  the  warfighter  when  needed,  it  and  the  program 
responsible  for  its  development  and  procurement  both  fail. 

This  does  not  imply  the  warfighter  is  the  only  stakeholder  in  a  tactical 
system.  On  the  contrary,  we  must  recognize  the  fact  that  every  American  from 
the  top  down  retains  some  interest  in  such  a  project.  For  instance,  the  U.S. 
Congress  allocates  a  program’s  funding  and  measures  its  ability  to  remain  on 
schedule  and  on  budget.  The  DoD  and  its  associated  projects  sometimes 
directly  or  indirectly  employ  the  constituents  of  these  Congressmen  and  women. 
The  program  management  team  and  responsible  contractors  have  interests  in 
seeing  their  program  reach  operational  status.  And  of  course,  the  American 
taxpayers,  in  support  of  national  defense,  provide  funding  for  all  DoD  projects. 
As  rightful  stakeholders,  these  people  all  share  valid  inputs,  concerns,  and 
interests,  but  they  do  not  determine  the  success  or  failure  of  a  program. 
Ultimately,  only  the  end  user — the  warfighter — can  declare  true  success  or  failure 
of  a  tactical  system. 
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The  first  increment  (Block  1)  of  the  Target  Location,  Designation  and 
Handoff  System  (TLDHS)  illustrates  a  warfighter’s  determination  of  success  vs. 
failure.  The  system  boasted  innovative  and  impressive  capabilities  as  it  allowed 
a  Forward  Air  Controller  to  precisely  determine  the  location  of  a  target  and 
digitally  send  this  location  to  a  Close  Air  Support  (CAS)  aircraft  overhead  for 
prosecution.  These  features  minimized  voice  communications  and  consequently 
decreased  the  chances  of  miscommunication.  Unfortunately,  the  warfighter  (the 
FAC)  did  not  value  Block  1  of  the  system  because  it  lacked  usability.  Because  of 
its  weight  and  bulk,  warfighters  found  it  difficult  to  carry.  They  also  had  trouble 
reading  its  display  in  sunlight.  Its  magnetic  compass  made  it  impossible  to  use 
near  vehicles.  Additionally,  it  required  a  lengthy  and  involved  setup  process  that 
included  multiple  cables,  attachments,  and  a  slow  processor  boot  up.  Because 
of  these  and  other  limitations,  the  user  did  not  value  the  system.  Its  lack  of 
usability  far  outweighed  the  benefits  it  offered  in  locating  targets  and  minimizing 
communications,  and  without  necessarily  saying  so,  the  warfighters  considered  it 
a  failure  as  just  another  40  lbs.  of  gear  they  had  to  carry  and  account  for. 

The  many  qualitative  and  quantitative  definitions  of  project  success  and 
failure  both  in  the  private  and  public  sectors  vary  widely.  In  the  business  of 
warfighting  though,  the  definitions  break  down  into  relatively  simple  terms: 
success  =  value  added  for  the  user;  failure  =  no  value  added. 

C.  WHY  DO  DOD  IT  SYSTEMS  FAIL  TO  SATISFY  THE  WARFIGHTER? 

With  firm  definitions  of  project  success  versus  failure,  this  section  will 
examine  some  of  the  causes  of  such  failure.  It  will  first  review  some  of  the  more 
universal  causes  of  project  or  program  failure  and  then  narrow  the  scope  to  look 
at  the  challenges  faced  by  the  government,  specifically  DoD,  acquisition 
programs  and  why  they  fail  to  deliver  user-valued  products. 

1.  Causes  of  “Failure”  Abound 

Using  a  more  generic  definition  of  project  failure  than  the  warfighter’s 

described  above,  IT  projects  fail  for  a  number  of  different  reasons  or  combination 
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of  reasons.  Various  organizations  and  experts  have  analyzed  this  subject  for 
decades  and  their  studies  usually  produce  lists  of  factors  that  contribute  to 
project  failure.  A  1994  Standish  CHAOS  Report  concluded  the  following  as  top 
factors  in  failed  projects  (Frese  &  Sauter,  2003).  Although  almost  15  years  old, 
this  list  preserved  comprehensive  and  relevant  points  that  still  contribute  to 
project  failures  today. 

•  Incomplete  requirements 

•  Lack  of  user  involvement 

•  Lack  of  resources 

•  Unrealistic  expectations 

•  Lack  of  executive  support 

•  Changing  requirements  and  specifications 

•  Lack  of  planning 

•  Project  no  longer  needed 

•  Lack  of  IT  management 

•  Technical  illiteracy 

Other  contributors  not  listed  in  the  report  deserve  at  least  mentioning.  For 
example,  developers  often  inadequately  understand  user  needs  (Field,  1997)  or 
the  users  poorly  communicate  their  needs  to  the  IT  development  team  (Hoffman, 
2003).  Additionally,  information  system  projects  often  take  place  in  an 
environment  characterized  by  the  following,  “[a]  lack  of  management  continuity 
and  an  incentive  system  that  encourages  overly  optimistic  estimates  of  the 
benefits  that  can  be  attained  from  doing  the  project.”  (Hulme,  1997) 

Acquisition  programs  in  the  DoD  are  simply  projects  (albeit  far  from  simple 
though)  and  as  such  involuntarily  expose  themselves  to  failure  due  to  the  above 
causal  factors.  Unfortunately,  DoD  projects  face  those  obstacles  as  well  as 
many  others  not  typically  encountered  by  private  industry.  Considering  the 
organizational  size  and  complexity  of  the  DoD  and  the  defense  industry,  the 
following  factors  additionally  challenge  the  success  of  their  IT  projects. 
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•  Inter-Service  rivalry  and  competition 

•  Lack  of  personnel  continuity  (GAO-08-782T,  2008) 

•  Ill-responsive  requirements  and  budget  process  (GAO-08-782T, 
2008) 

•  Dislocated,  uninformed  and  disinterested  user  community 

•  Inexperienced  or  unqualified  acquisition  workforce  (GAO-08-1 159T, 
2008) 

•  Event-driven  projects  executing  a  time-driven  budget 

•  Onerous  oversight  via  rules,  regulations  and  reporting  requirements 
(GAO-06-110,  2006) 

•  Numerous  integration  and  interoperability  requirements 

•  Risk  and  change  averseness 

•  Failure  averseness  (inability  to  dismiss  sunk  costs)  (GAO-08-379, 
2008) 

•  Lack  of  user  training 

•  Lack  of  post-deployment  support 

•  Self-gratifying  and  inappropriately  motivated  incentive  system 
(GAO-08-782T,  2008) 

•  Overly  optimistic  cost  and  schedule  estimates  (GAO-06-1 10,  2006) 

2.  Why  Do  Projects  Fail  to  Provide  Value  to  the  User? 

The  lists  above  offer  some  insight  into  the  causes  of  generic  project 
failure.  Narrowing  the  scope  of  this  analysis,  consider  the  warfighter’s  definition 
of  failure  as  described  in  the  preceding  sections.  Using  that  definition,  why  would 
a  project  fail,  or  more  precisely,  why  would  a  system  not  deliver  value  to  the 
user?  The  reasons  logically  divide  into  two  broad  categories:  either  (1)  some 
aspect  of  the  system  does  not  provide  value  to  the  user  or  worse,  hinders  the 
user,  or  (2)  the  system  did  not  meet  the  user’s  required  timeline. 

a.  Causes  of  Failure  -  System  Aspects 

The  first  category  is  relatively  simple  -  the  intended  user  finds  no 
satisfaction  due  to  a  shortfall  of  the  system  relative  to  their  needs  or  desires. 
These  user  goals  cover  a  broad  spectrum  of  system  requirements  related  to  its 
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performance  and  physical  characteristics,  such  as  usability,  reliability, 
transportability,  maintainability,  etc.  Inadequacies  in  these  areas  contribute  to 
project  failure  because  they  devalue  the  system  in  the  eyes  of  the  user. 
Obviously,  different  levels  of  consequence  exist  in  this  category.  On  one 
extreme  as  an  example,  the  system  burdens  more  than  benefits  the  user  and  as 
a  result,  it  actually  decreases  the  warfighter’s  effectiveness  and  retains  no  value 
whatsoever.  At  the  other  end  of  the  spectrum,  the  system  takes  on  some,  but 
not  much  value.  An  example  of  this  could  include  a  lack  of  organizational 
support  for  a  decent  system  because  of  inadequate  training  or  spare  repair  parts. 
These  relate  to  a  failure  of  some  aspect  of  the  system  itself,  and  they  all  reduce 
the  value  the  user  places  on  it,  thereby  increasing  its  chance  of  ultimate  failure. 

b.  Causes  of  Failure  -  Lack  of  Timeliness 

The  second  category  of  contributions  to  tactical  IT  project  failure  is 
more  abstract  than  the  first,  but  it  cripples  a  project  just  as  much,  if  not  more  so. 
These  factors  relate  to  the  speed  at  which  value  reaches  the  user.  Before  the 
1990s,  system  design  used  a  traditional  waterfall  approach  or  a  single  step  to  full 
capability  (SSFC).  This  process  identified  a  capability  gap;  developed  an  item  to 
fill  that  gap;  built,  tested,  fielded  it  and  subsequently  supported  it  for  the  next  few 
decades  until  the  product  reached  its  end  and  required  replacement.  This  slow 
process  worked  well  for  hardware  intensive  systems  where  the  identified 
capability  gap,  or  target,  stayed  relatively  stationary  and  immune  to  technological 
volatility.  Programs  did  not  rush  to  complete  the  project  because  the  target 
remained  when  the  piece  of  hardware  rolled  off  the  production  line.  For  example, 
the  legacy  military  Jeep  and  its  replacement,  the  High  Mobility  Multi-purpose 
Wheeled  Vehicle  (HMMWV)  well  illustrate  this.  The  acquisition  target,  or  desired 
capability  of  lightweight  vehicular  transportation,  persisted  throughout  the 
HMMWV’s  development  and  production,  and  was  therefore  relatively  easy  to  hit. 
Ultimately  the  users  valued  the  product  because  the  requirement  defined  in  1981 
remained  valid  through  system  delivery  in  1985  and  beyond.  The  program  hit  the 

target  and  the  military  considered  it  a  success. 
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However,  since  then  software  has  assumed  many  functions 
historically  accomplished  by  hardware.  IT  now  permeates  most  military  systems, 
and  as  a  result,  the  SSFC  method  of  acquisition  has  become  less  appropriate. 
Today,  the  target  no  longer  cooperates  by  remaining  stationary  because  of  the 
rapid  rate  of  technological  change.  Timeliness  of  acquisition  has  pervaded  its 
way  into  the  equation  for  project  success.  Using  a  slow,  inflexible  process  to 
develop  and  produce  an  IT  system  likens  to  taking  slow,  methodical  aim  at  a 
distant,  randomly  moving  target.  This  equates  to  a  kiss  of  death  for  an  IT  project 
because  of  the  target’s  seemingly  unpredictable  movements,  and  the  system  will 
never  succeed  in  its  aim.  By  the  time  the  system  achieves  delivery,  the  target 
has  changed  and  the  user  will  not  value  it  (e.g.  it  fails)  for  multiple  reasons.  The 
paragraphs  below  provide  details  on  some  of  these  reasons. 

(1)  Project  No  Longer  Needed.  Determining  a  formal 
requirement  for  a  DoD  acquisition  program  requires  time,  sometimes  years.  The 
Joint  Capabilities  Integration  and  Development  System  (JCIDS)  process  provides 
the  means  to  “ensure  the  joint  warfighter  receives  the  capabilities  required  to 
successfully  execute  the  missions  assigned  to  them”  (CJCSI  31 70.01  F,  2007). 
Unfortunately,  this  process  takes  an  exorbitant  amount  of  time  and  requires 
numerous  approvals  before  finalization  of  a  formal  requirements  document.  The 
requirement  feeds  the  Defense  Acquisition  System,  which  translates  the  desired 
capability  into  an  acquisition  program  (DoDI  5000.02,  2008). 

The  time  required  to  develop  and  produce  a  system  varies 
greatly  depending  on  a  number  of  different  factors  including  the  system’s 
complexity,  technological  maturity,  and  the  number  of  stakeholders,  to  name  a 
few.  Throughout  this  prolonged  process  of  identifying  a  requirement,  acquiring 
program  funding,  developing  and  finally  producing  a  system,  the  requirement 
likely  will  change...  possibly  due  to  an  environmental  or  technological  change  or 
any  one  of  a  number  of  other  reasons.  As  a  hypothetical  example,  a  radio 
frequency  jamming  device  intended  to  counter  wirelessly  detonated  improvised 
explosive  devices  (lEDs)  becomes  operational  after  insurgents  have  switched 
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tactics  and  now  detonate  their  lEDs  using  some  other  means.  The  user  views 
the  jammer  as  irrelevant  and  unsuccessful  even  though  it  may  effectively  jam 
detonation  signals.  Due  solely  to  its  tardiness,  the  system  fails  because  it 
burdens  users  as  yet  another  item  they  have  to  account  for,  train  on,  maintain, 
transport,  store,  etc.  In  these  situations,  no  system  at  all  provides  more  value 
than  a  late  system.  As  General  James  Cartwright,  the  Vice  Chairman  of  the  Joint 
Chiefs  of  Staff  said,  "It  takes  longer  to  declare  a  new  [program]  start  than  the 
lifecycle  of  the  software  package."  (Boessenkool,  2009)  Rapid  change  truly 
marks  the  information  age,  and  slow-developing  IT  systems  often  reach  users 
only  to  fail  in  satisfying  recently  changed  or  invalidated  requirements.  The  user 
does  not  need  the  tactical  system  provided  and  disappointment  results.  The 
system  fails. 

(2)  Event-driven  Projects  Executing  a  Calendar-driven 
Budget.  The  Planning,  Programming,  Budgeting  and  Execution  System 
(PPBES)  requires  a  calendar-driven  sequence  of  events  while  the  DAS  follows 
an  event-driven  schedule  (Jones,  McCaffery,  &  Fierstine,  2005).  This  means 
DAS  programs  must  demonstrate  increasing  maturity  and  readiness  as  they 
approach  eventual  fielding.  These  programmatic  demonstrations,  defined  very 
early  in  a  program’s  lifecycle,  occur  as  readiness  reviews  and  milestones  and 
require  formal  approval  by  the  milestone  decision  authority.  As  a  technologically 
intensive  system  proceeds  through  the  DAS,  beneficial  innovations  sometimes 
allow  them  to  accelerate  their  schedule  and  potentially  provide  a  capability  to  the 
warfighter  sooner  than  expected.  However,  the  PPBES,  inflexibly  calendar- 
driven  in  nature,  does  not  allow  for  such  change  and  requires  a  program  to 
remain  on  schedule  as  technological  innovations  come  and  go.  As  Mr.  Robert 
Carey,  the  Navy’s  Chief  Information  Officer  (CIO)  said  in  a  recent  interview, 

Things  are  moving  really  fast.  The  acquisition  system,  and  more 
importantly  the  budgeting  system,  moves  at  a  different  pace... 

Today,  if  most  of  you  come  in  and  say,  'I've  got  this  great  idea.  I 
want  to  give  it  to  you,'  all  of  our  money  has  been  displaced...  There 
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is  little  agility  in  that  system.  When  you  go  spend  it  on  something 
else,  an  opportunity,  you  generally  have  to  break  something  else.” 
(Boessenkool,  2009) 

More  common  than  an  opportunity  to  accelerate  though,  is 
the  occurrence  of  some  problem  in  the  process  causing  a  schedule  delay  or  an 
inability  to  execute  its  budget.  The  PPBES  not  only  discourages  such  change,  it 
effectively  punishes  it  through  a  use-it-or-lose-it  mentality.  In  other  words,  if  a 
program  cannot  execute  funds  before  they  expire,  it  will  probably  lose  those 
funds  to  a  program  that  can  execute  them.  As  an  additional  consequence,  it  will 
have  a  much  harder  time  justifying  keeping  its  funds  in  future  years.  This 
inflexibility  can  have  a  compounding  negative  effect  of  spiraling  a  program  into 
further  delays,  which  allows  mainstream  technological  capabilities  to  outrun  the 
program’s  original  requirements  until  the  first  bullet  above  comes  to  fruition:  the 
need  for  the  project  disappears  and  it  ultimately  fails  to  deliver  anything  of  value 
to  the  user. 

(3)  Lack  of  Personnel  Continuity.  The  USMC  has 

recognized  the  importance  of  a  qualified  acquisition  workforce  and  strives  to 

better  support  it  through  the  creation  of  new  military  occupational  specialties 

(MOS),  continuing  education,  and  centers  of  excellence.  These  efforts, 

respectable  as  they  are,  do  not  solve  the  personnel  continuity  problem  in  the 

acquisition  community  though.  USMC  Manpower  and  Reserve  Affairs  requires 

military  members  to  continue  duty  rotations  every  three  years.  If  a  workforce 

member  arrives  at  his  acquisition  command,  new  to  military  acquisitions  and 

unfamiliar  with  its  vocabulary,  organizations,  and  requirements,  it  will  take  about 

a  year  before  he  or  she  effectively  contributes  to  a  program.  During  this  action- 

officer  learning  time  a  program  seldom  advances  as  quickly  and  effectively  as  it 

would  with  an  experienced  acquisition  professional  at  the  helm.  Although  hard  to 

justify  one  person  holding  an  entire  program  back,  when  that  program 

encounters  personnel  changes  continuously,  negative  effects  inherently 

accumulate  and  the  program  suffers.  Furthermore,  considering  the  slow  pace  of 

military  acquisitions  where  three  years  might  encompass  only  a  single  phase  of  a 
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program’s  procession  through  the  DAS,  the  program  may  potentially  have 
multiple  managers  and  project  officers  throughout  its  lifecycle,  each  of  whom 
requires  separate,  time-consuming  learning  curves.  Because  of  this  fact,  the 
program’s  institutional  memory  and  tacit  knowledge  constantly  and  quickly  fades; 
lessons  learned  go  undocumented  and  subsequently  require  relearning,  further 
challenging  any  programmatic  advancement.  This  discontinuous  knowledge 
limits  a  program’s  progress  and  schedule  delays  result,  both  of  which  can  lead  to 
eventual  project  failure. 

(4)  Onerous  Documentation,  Regulations  and  Reporting 
Requirements.  Although  the  DAS  encourages  streamlining  the  acquisition 
process,  its  efforts  fall  short  of  the  efficiency  and  speed  necessary  to  exist  as  a 
viable  means  to  procure  IT  systems.  On  the  surface,  the  DAS  instruction 
appears  to  support  flexibility,  which  logically  improves  the  process.  But  the 
numerous  statutory  and  regulatory  requirements  levied  upon  even  small 
programs  render  the  process  anything  but  easy.  The  tables  in  the  DoDI  5000.02 
reveal  the  documentation  required  for  a  program  offering  a  mature  technology  to 
enter  the  process  at,  for  example,  Milestone  C  (Production  and  Deployment):  14 
different  statutory  requirements  and  26  regulatory  requirements...  40  different 
documents,  all  of  which  require  review  and  approval  up  a  hierarchical  chain  of 
command.  The  generation  of  such  a  mound  of  paperwork  and  its  subsequent 
approval  do  not  happen  overnight.  In  fact,  the  process  takes  months  or 
sometimes  years.  Although  the  documentation  requirements  arguably  intend  to 
protect  the  American  taxpayer  from  wasting  money  on  failed  acquisition 
programs,  they  often  have  the  opposite  effect,  further  delaying  an  already  slow 
process  to  a  point  where  the  user  no  longer  values  the  end  product. 

The  four  categories  above  illustrate  how  a  program  can  fall  victim  to 
the  numerous  time  taxes  and  distracters  that  delay  system  delivery  to  the  user. 
In  the  information  age,  the  value  a  warfighter  places  on  a  specific  solution  stales 
quickly,  so  any  delays  in  the  provision  of  that  solution  lead  to  decreased  value 
and  can  spell  eventual  failure  for  the  system  and  its  associated  program.  Speed 

18 


increases  value;  likewise,  lateness  provides  little  value.  This  cause  of  failure  due 
to  a  lack  of  acquisition  timeliness  defines  the  second  of  two  broad  categories 
discussed,  the  first  being  system-specific  causes  of  failures.  One  other 
contributor  to  DoD  IT  project  failure  does  not  fit  neatly  into  either  category,  but 
deserves  mentioning  here.  It  relates  to  the  operator’s  perception  of  military 
acquisitions. 

Warfighters  unfamiliar  with  the  acquisition  world  typically  hold  a 
negative  view  of  DoD  acquisitions...  and  for  good  reason.  They  identify 
operational  needs  for  the  acquisitions  process  and  sometimes  participate  in  the 
formal  requirements  generation  events  or  user  juries.  But  seldom  during  their 
current  tour  (typically  about  3  years)  will  they  actually  see  a  system  go  from 
inception  to  successfully  operational,  satisfying  those  needs.  This  unfortunate 
fact  again  occurs  due  to  the  typically  slow  and  unresponsive  acquisition  process. 
The  users  maintain  sad  awareness  that,  for  reasons  mostly  unknown  to  them,  it 
takes  years  to  define,  develop,  test,  and  deploy  a  system  in  the  DoD.  This 
awareness  combined  with  the  dissatisfaction  from  inadequate  support  plans  for 
many  existing  systems  has  led  to  a  distrustful  attitude  on  the  part  of  the  user 
community  that  greatly  contributes  to  prejudices  against  new  systems.  Sarcastic 
phrases  such  as  “drive-by  fielding”  or  “another  ‘fine’  product  from  Systems 
Command”  evidence  this  cynicism.  Failures  of  new  systems  sometimes  spiral 
into  self-fulfilling  prophesies  due  to  these  types  of  prejudices.  The  user  declares 
the  new  system  a  failure  before  ever  giving  it  a  fair  chance  at  success. 

When  these  perceptions  and  prejudices  apply  to  an  IT-intensive 
system  highly  susceptible  to  technological  progression  laws  such  as  Moore’s,  2 
Butter’s,  3  and  Kryder’s,4  the  user’s  negative  view  of  military  acquisitions 


2  Gordon  Moore’s  Law  states  that  the  number  of  components  per  integrated  circuit  doubles 
every  24  months  (ComputerHistory.org,  2007). 

3  Gerry  Butter’s  Law  states  that  the  amount  of  data  we  are  able  to  transmit  through  an  optical 

medium  doubles  every  9  months  (Robinson,  2000). 


19 


entrenches  even  more  firmly.  In  the  deployment  phase  of  the  acquisition  cycle, 
the  user  receives  IT  systems  that  often  incorporate  obsolete  technology,  usually 
due  solely  to  the  slow  speed  of  the  acquisition  process.  Furthermore,  the  user 
has  a  keen  awareness  of  the  system’s  obsolescence  because  today’s 
warfighters,  as  members  of  the  information  generation,  maintain  a  solid  grasp  on 
the  technological  trends  of  the  day.  They  unfortunately  judge  the  performance  of 
military  systems  against  the  commercial  systems  found  on  the  shelves  of  their 
local  electronics  retailer  and  in  such  comparisons,  the  military  systems  fall  short 
every  time.  Simply  put,  the  warfighter  values  the  availability  of  current 
technology  and  objects  to  the  provision  of  old  technology.  This  again  illustrates 
the  value  of  a  timely  acquisition  process. 

A  better  means  of  acquisition — a  more  agile,  responsive  process 
that  focuses  on  providing  incremental  value  to  the  user  in  rapid  succession — 
could  greatly  lessen  the  negative  impacts  of  some  of  these  factors  contributing  to 
user  dissatisfaction  and  project  failure.  This  holds  especially  true  for  IT 
acquisition  projects  subjected  to  both  obsolescence  and  constantly  changing 
targets.  Using  the  previously  stated  definitions  of  success  and  failure,  delays 
greatly  exacerbate  the  impacts  of  most  of  the  above  causal  factors  and 
effectively  push  projects  closer  to  failure.  On  the  other  hand,  decreasing  the  so- 
called  time  to  market  followed  by  rapid,  iterative  improvements  will  increase 
value  and,  consequently,  the  program’s  chances  of  success.  Considering  these 
observations,  the  acquisitions  process  in  the  DoD  needs  rapid,  value-based, 
evolutionary  acquisition. 


4  Mark  Kryder’s  work  involves  analyzing  the  impacts  of  exponentially  increasing  bit 
storage  capacity  relative  to  physical  component  size,  and  he  hypothesized  that  magnetic 
disk  areal  storage  density  doubles  annually  (Walter,  2005). 
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III.  RAPID,  VALUE-BASED  EVOLUTIONARY  ACQUISITION5 

Throughout  history,  environmental  changes  have  caused  adaptive 
adjustments  in  the  methods  and  management  techniques  used  by  organizations 
to  develop  and  produce  items.  Organizations  realized  a  need  for  improvement 
and  they  adjusted  their  methods  accordingly.  For  example,  the  increasing 
complexity  of  systems  along  with  an  expanding  environment  in  the  mid-1900s 
gave  rise  the  discipline  of  systems  engineering  (Hall,  1962).  Project 
management  illustrates  another  example  of  such  an  adjustment.  Although 
practiced  for  centuries,  its  formalization  as  a  discipline  did  not  occur  until  the 
1950s  when  managers  saw  a  need  to  approach  projects  from  an  integrated 
perspective,  methodically  accounting  for  complexities  between  cost,  schedule 
and  performance  of  systems  (Cleland  &  Gareis,  2006).  Most  recently,  the  past 
two  decades  have  witnessed  a  dynamic  shift  in  the  commercial  sector’s  ability  to 
produce  technologically  superior  products  compared  to  the  military.  Historically 
sought  after  because  of  its  toughness  and  rigorous  Military  Specification 
(MILSPEC)  standards,  the  equipment  of  the  defense  industry  previously 
pioneered  technological  advancements,  and  commercial  applications  of  the 
innovations  typically  followed.  But  the  market’s  insatiable  demand  for  the  cutting- 
edge  capabilities  stimulated  a  role  reversal.  Private  industry  assumed  the 
military’s  role  as  technological  pioneer,  and  the  latest  products,  after  proven 
commercially,  seek  applications  in  the  military  (Alberts,  Garstka,  &  Stein,  1999). 
Furthermore,  the  military  has  increasingly  less  influence  on  the  private  sector 
because  of  its  declining  share  of  the  IT  market  as  shown  in  Figure  2  (Stogdill, 


5  The  name,  Rapid,  Value-based,  Evolutionary  Acquisition  (RVEA),  is  mostly  credited  to 
Chris  Gunderson,  David  Minton  and  Rick  Hayes-Roth  from  their  whitepaper  entitled,  “Value- 
Based  Acquisition:  An  Objective,  Success-Centric,  Evolutionary  Approach.”  Although  this 
approach  has  other  additional  attributes,  this  thesis  emphasizes  its  rapid,  value-based,  and 
evolutionary  nature  as  its  three  most  important  qualities,  and  therefore  coins  the  name  RVEA. 
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1999).  In  a  reactionary  effort  to  take  advantage  of  these  commercially 
developed,  technologically  mature  items,  the  DoD  conceived  evolutionary 
acquisition  (EA). 


Figure  2.  Military's  Integrated  Circuit  Market  Share  (From  Stogdill) 

EA,  in  policy,  proposed  an  improvement  in  military  acquisition  because  it 
allowed  development  of  capabilities  in  increments,  as  opposed  to  forcing  the  use 
of  the  traditional  waterfall  method.  Additionally,  the  DoD  instruction  implementing 
EA  declared  it  as  the  “preferred”  acquisition  method  and  theoretically  provided 
flexibility  to  procure  mature  technologies  relatively  rapidly,  instead  of  requiring  full 
procession  through  development,  engineering,  and  testing  (DoDI  5000.02,  2008). 
EA  looked  like,  at  least  on  paper,  a  step  in  the  right  direction  to  account  for  yet 
another  environmental  change. 

A.  THE  REQUIREMENT  FOR  RVEA 

The  DoD  created  EA  for  relatively  simple  reasons:  react  to  environmental 
factors  of  (1)  increasing  systems  complexity  and  the  related  requirement  for 
better  planning,  and  (2)  increasing  demand  for  flexibility  and  rapidity.  Certainly, 
the  pressures  that  spawned  systems  engineering,  project  management,  and  EA 
as  illustrated  above  pertain  today.  Continual  improvement  necessitates  further 
adjustment  beyond  simple  EA  in  order  to  optimize  our  response  to  these  forces. 
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As  mentioned,  the  DAS  prefers  EA  as  its  acquisition  method  in  policy,  and 
at  first  glance  considering  the  enlightening  language  of  some  of  the  acquisition 
regulations,  one  might  believe  EA  contains  the  sought-after  improvement 
sufficient  to  improve  acquisition  effectiveness.  After  all,  it  sounds  good  on  paper, 
but  according  to  the  GAO,  DoD  has  yet  to  implement  true  evolutionary 
development  in  practice  (GAO-06-110,  2006).  The  GAO  uses  the  Joint  Strike 
Fighter  as  an  example  of  a  current  program  attempting  to  provide  too  many 
significant  capability  improvements  in  a  single  step  rather  than  providing 
incremental  improvements  in  capabilities  over  time.  Such  overly  ambitious 
capability  leaps  inevitably  result  in  schedule  delays,  neglecting  the  importance  of 
timeliness  (providing  value  to  the  user  as  quickly  as  possible).  Additionally, 
attempting  to  provide  a  100%  solution  predictably  causes  other  problems  such  as 
cost  overruns  and  considerable  interoperability  challenges.  Although  the  DoD 
has  recognized  the  requirement  for  an  evolutionary  acquisition  method  and 
attempted  to  implement  it  in  policy,  in  actuality  the  process  still  desperately 
needs  improvement. 

Another  evolutionary  environmental  force  alive  and  well  today  relates  to 
our  dependence  on  IT,  and  considering  the  ambitious  goals  of  defense  systems 
now  compared  to  only  a  few  years  ago,  this  dependence  will  only  increase. 
Combine  our  escalating  dependence  with  the  dismal  success  rate  of  information 
systems  projects  described  in  a  previous  section,  and  most  of  the  high 
aspirations  for  information  systems  supporting  national  defense  will  probably 
never  materialize...  unless  we  find  and  implement  a  better  means  of  acquiring 
those  systems. 

B.  THE  FOUNDATION  OF  RVEA 

National  defense  today  demands  harnessing  the  power  of  information. 
Our  highest  leaders  have  recognized  information’s  strategic  and  tactical 
importance  (DoD  Information  Management  and  Information  Technology  Strategic 
Plan,  2008-2009)  as  evident  in  concepts  such  as  full  spectrum  dominance, 
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information/net-centric  operations  and  warfare,  systems  of  systems,  and  the 
Global  Information  Grid,  to  name  a  few.  These  concepts  aspire  to  improve 
decisions  largely  based  on  information.  It  therefore  makes  sense  that 
possessing  better  information  and  processing  it  more  effectively  and  efficiently 
than  the  enemy  will  lead  to  better,  faster  decisions,  which  in  turn  will  produce 
better  outcomes.  Joint  Publication  3-13  calls  this  ability  Information  Superiority: 
“The  operational  advantage  derived  from  the  ability  to  collect,  process,  and 
disseminate  an  uninterrupted  flow  of  information  while  exploiting  or  denying  an 
adversary’s  ability  to  do  the  same”  (Joint  Publication  3-13,  2006). 

Militaries  cannot  accomplish  information  superiority  overnight,  nor  can 
they  achieve  it  and  then  forget  about  maintaining  it.  Instead,  information 
superiority  embodies  a  position  that  our  forces  must  first  deliberately  attain,  and 
then,  just  as  important  and  perhaps  more  difficult,  effectively  maintain  and 
exploit.  Gaining  and  holding  a  superior  information  position  requires  a  highly 
effective  process  of  continual  improvement,  staying  a  step  ahead  of  the  enemy 
by  focusing  on  value  and  speed...  a  process  in  which  information  systems 
technology  has  become  a  critical  enabler. 

Coincidentally,  the  process  of  achieving  information  superiority  has  many 
noteworthy  similarities  to  the  process  we  should  use  to  develop  and  procure  its 
supporting  technologies  and  ultimately  provide  value  to  the  user.  Three  of  these 
similarities — value-based,  rapid,  and  continual  improvement — form  the 
foundation  of  RVEA  and  the  following  sections  describe  the  qualities  of  this 
process,  pointing  out  similarities  with  the  process  of  attaining  information 
superiority. 

1.  Value-based 

The  book,  Network  Centric  Warfare,  states  that  exploitation  of  a  superior 
information  position  results  in  a  competitive  advantage,  which  in  turn  creates 
information  superiority.  The  book  goes  on  to  say  that  the  “creation  of  value  is  at 
the  heart  of  creating  [this]  competitive  advantage.”  (Alberts,  Garstka,  &  Stein, 
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1999)  The  information  collected,  communicated  and  exploited  in  attaining 
information  superiority  therefore  requires  value.  Without  value  or  meaning, 
information  merely  contributes  to  info-glut  and  clouds  situations,  increasing  the 
fog  of  war,  which  consequently  decreases  combat  effectiveness  (Hayes-Roth, 
Model-based  Communication  Networks  and  VIRT:  Filtering  Information  by  Value 
to  Improve  Collaborative  Decision-Making,  2005). 

One  cannot  discuss  the  concept  of  information  value  without  also 
mentioning  how  value  is  determined,  or  more  appropriately,  who  determines 
value.  Decision-makers  and  operators  define  the  value  of  information  based 
upon  its  ability  to  contribute  to  their  knowledge  of  a  situation,  and  their  input 
therefore  determines  what  information  to  filter  or  forward.  Imperative  here  is  who 
defines  value:  not  the  system  developer  or  administrator  of  the  filter  mechanism; 
instead,  the  decision  maker  decides  value.  Operational  commanders  as 
decision-makers  practice  this  concept  routinely  by  defining  commander’s  critical 
information  requirements. 

While  the  process  of  achieving  information  superiority  relies  on  the 
production  of  valued  information,  an  acquisition  process  must  similarly  produce 
valued  operational  products.  As  described  in  the  previous  section  defining 
project  success  and  failure,  the  user  of  such  a  product  measures  value  in  terms 
of  its  ability  to  improve  his  or  her  job,  just  as  the  user  of  information  defines  its 
value  based  upon  how  it  improves  their  decisions.  For  this  reason,  user 
involvement  rises  to  an  essential  level  in  the  acquisition  process...  not  only  the 
requirements  definition  phase,  but  also  the  system’s  development,  testing  and 
beyond.  Employing  users  in  this  manner  first  ensures  value  as  an  objective  and 
second  confirms  a  system’s  ability  to  provide  that  value.  Likewise,  neglecting 
user  input  at  these  critical  points  will  lead  to  the  developer  assuming  what 
defines  user  value,  and  the  system  will  likely  miss  the  mark,  which  will  certainly 
contribute  to  the  project’s  ultimate  demise. 
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2.  Rapid 

The  pace  of  life  continues  to  accelerate.  Each  decade,  the  speed  required 
for  achieving  success  markedly  increases.  Society  demands  swiftness  for  the 
reporting  of  news,  weather,  market  quotes  and  other  types  of  information 
because  the  value  of  that  information  decreases  over  time.  We,  as  members  of 
society,  also  require  the  ability  to  instantly  and  remotely  communicate  with  each 
other,  and  technology  allows  us  to  do  so  through  email,  text/instant  messaging, 
etc.  The  relatively  high  speed  these  capabilities  offer  assists  in  making  us  more 
knowledgeable  and  efficient  than  without  them. 

Warfare  also  moves  at  a  more  rapid  pace  today  than  in  previous  decades, 
and  combatants  sometimes  win  battles  because  of  an  ability  to  achieve  and 
exploit  a  superior  information  position  partially  due  to  rapidity.  Capitalizing  on  a 
superior  information  position  requires  timeliness  or  speed  for  two  reasons.  First, 
we  must  collect,  analyze,  act  upon  information,  and  then  repeat  the  process 
more  quickly  than  the  enemy  can.  Boyd  called  this  “getting  inside  the 
adversary’s  OODA  loop.”  (Boyd,  1986)  Originally  applying  this  concept  to  air 
combat  maneuvering  (ACM)  in  the  Korean  War,  he  won  visual  aerial  combat 
engagements,  or  dogfights,  by  observing,  orienting,  deciding  and  acting 
(completing  the  OODA  loop)  repetitively  faster  than  his  opponent  could.  This 
technique  eventually  placed  him  in  an  advantageous  position  that  he  capitalized 
on  in  the  form  of  weapons  employment.  Boyd  captured  this  technique  in  his 
writings  as  a  military  strategist  and  it  has  since  seen  application  to  larger-scale 
competitions,  including  gaining  a  strategic  advantage  in  modern  conflicts  such  as 
Operation  Desert  Storm  in  1991  (Cowan,  2000).  Possessing  a  faster  decision 
cycle  contributes  to  one’s  ability  to  achieve  and  exploit  information  superiority. 

The  second  reason  speed  matters  greatly  for  information  superiority 
derives  from  the  perishability  of  information.  The  longer  information  sits 
unattended,  the  staler  it  becomes.  In  war,  this  fact  results  primarily  from  the  fast 
rate  of  change  of  the  battlespace.  Operational  forces  have  the  same  demands 

as  society  for  current — as  close  to  real  time  as  possible — information  because  it 
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quickly  stales,  especially  in  wartime.  Old  information  often  equates  to  inaccurate 
information  due  to  an  unobserved  change  in  the  situation,  and  it  seldom 
produces  optimal  decisions  because  of  this  inherent  inaccuracy.  In  fact,  no 
information  is  usually  better  than  inaccurate  information  because,  lacking 
information  concerning  a  situation,  commanders  will  make  typically  conservative 
estimates,  fully  realizing  they  cannot  accurately  grasp  the  situation’s  reality. 
Whereas  unknowingly  using  inaccurate  or  stale  information  gives  rise  to 
suboptimal  or  even  wrong  decisions.  Commanders  therefore,  just  like  society, 
require  current  information  in  order  to  increase  their  knowledge  and  efficiency, 
effectively  improving  the  quality  of  their  decisions  in  pursuit  of  information 
superiority.  Rapid  observation  and  analysis  of  a  situation  followed  by  quick 
decisions  and  actions  form  key  enablers  of  this  ability.  Bottom  line:  speed 
increases  value. 

Speed  also  translates  into  increased  value  in  the  acquisition  process  for 
reasons  similar  to  those  above  in  attaining  information  superiority.  The  ability  to 
observe,  orient,  decide  and  act  more  quickly  than  our  opponent  allows  us  to  get 
inside  his  loop  and  achieve  a  competitive  advantage.  Likewise,  we  must  get 
inside  the  loop  of  our  opponent  in  the  acquisition  process,  but  on  the  acquisitions 
battlefield  the  enemy  lurks  as  both  external  and  internal  forces.  Externally,  the 
current  enemy  is  the  same  as  in  the  Global  War  on  Terror,  a  wily  and  quickly 
adaptive  adversary  not  bound  by  acquisition  rules  and  regulations  or  even  the 
Geneva  Conventions.  His  weapons  include  lEDs  and  suicide  bombers,  and  only 
their  imagination  and  budget  limit  their  capabilities.  Internally  however,  the 
enemy  resides  within  a  slow  acquisition  process  which  cannot  cope  with  a  rapidly 
changing  environment,  and  it  wields  weapons  of  technology  obsolescence  and 
changing  requirements. 

Focusing  on  the  internal  enemy,  the  acquisition  cycle  time,  or  loop,  must 
operate  faster  than  the  forces  of  obsolescence  and  requirements  change,  both  of 
which  devalue  a  system  in  the  eyes  of  an  operator,  just  as  time  decays  and 
devalues  information  supporting  an  operational  commander.  To  quantify  this 
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concept,  obsolescence  occurs  constantly,  but  in  general,  commercially  available 
technology’s  planned  lifecycles  survive  only  about  18-24  months,  paralleling 
Moore’s  Law  (Beck,  2003).  Requirements  changes  follow  a  similar,  albeit  less 
predictable  pattern,  influenced  by  factors  such  as  the  global  security 
environment,  adversary’s  capabilities,  and  technological  advancements.  RVEA 
should  therefore  strive  to  provide  an  operational  capability  within  no  more  than  2 
years  after  deciding  upon  a  particular  technology.  The  risk  of  not  doing  so  could 
easily  result  in  fielding  an  obsolete  or  unnecessary  system. 

Denning,  Gunderson  and  Hayes-Roth  articulate  the  significance  of  a  short 
acquisition  cycle  time: 

Development  time  is  the  critical  factor.  This  is  the  time  to  deliver  a 
system  that  meets  the  requirements  set  at  the  beginning  of  the 
development  process.  If  development  time  is  shorter  than  the 
environment  change  time,  the  delivered  system  is  likely  to  satisfy  its 
customers.  If,  however,  the  development  time  is  long  compared  to 
the  environment  change  time,  the  delivered  system  becomes 
obsolete,  and  perhaps  unusable,  before  it  is  finished.  In 
government  and  large  organizations,  the  bureaucratic  acquisition 
process  for  large  systems  can  often  take  a  decade  or  more, 
whereas  the  using  environments  often  change  significantly  in  as 
little  as  18  months  (Moore’s  Law).  (Denning,  Gunderson,  &  Hayes- 
Roth,  2008) 

Figure  3  illustrates  this  problem  by  depicting  a  desired  increase  in  capability  over 
a  few  years.  A  system  using  a  single  step  approach  (top  graph)  or  even  a 
lengthy  incremental  evolutionary  approach  (middle  graph)  risks  missing  the 
target  primarily  because  of  the  prolonged  time  to  value.  The  question  marks  on 
the  graphs  indicate  the  uncertainty  involved  in  aiming  at  a  distant,  randomly 
moving  target.  The  long-term  requirements  freeze  many  years  before  planned 
delivery.  This  early  target  determination  occurs  too  prematurely  to  estimate  (1) 
exactly  how  requirements  will  change  or  (2)  what  new  technological  innovations 
will  arise  over  the  course  of  those  years,  either  of  which  stand  to  lessen  the  value 
of  or  even  nullify  the  system  in  the  operator’s  opinion.  The  bottom  graph  depicts 
the  alternative,  which  provides  value  to  the  user  in  much  shorter  increments  than 
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the  middle  graph,  and  then  repeats,  effectively  allowing  continual  retargeting,  as 
opposed  to  risking  missing  a  long-range,  potentially  infeasible  target  defined 
years  earlier.6 


Figure  3.  Desired  Capability  vs.  Time.  The  progression  of  charts  from  top 
to  bottom  illustrate  different  approaches  to  managing  acquisition, 
ranging  from  a  “ballistic”  attempt  to  deliver  desired  capability  in  a 
single  cycle  to  a  rapid  adaptive  approach  with  multiple  short  cycles 


6  The  graphs  in  Figure  3.  are  adapted  from  a  classroom  discussion  from  Dr.  Hayes-Roth’s 
Information  Systems  Strategy  and  Policy  at  the  Naval  Postgraduate  School. 
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continually  re-aimed  toward  the  next  target  of  incrementally 
improved  capability.  (From  Hayes-Roth) 

Expanding  on  Boyd’s  ACM  analogy,  the  tactical  aircraft  saying,  “Speed  is 
life!”  further  illustrates  the  value  of  rapidity.  Fighters  require  high 
maneuverability,  and  lacking  sufficient  speed,  they  cannot  maneuver  to  attack  or 
defend.  In  aerial  combat,  bleeding  airspeed  is  relatively  easy,  but  opportunities 
to  gain  airspeed  in  the  visual  arena  seldom  occur.  For  this  reason,  possession  of 
a  speed  or  energy  advantage  creates  a  competitive  advantage  over  the  enemy.7 
Alternatively,  in  a  visual  air-to-air  engagement  if  a  fighter  pilot  finds  himself 
excessively  slow  against  an  opponent  who  has  and  maintains  an  energy 
advantage,  the  opponent  will  eventually  gain  an  offensive  position  because  of  his 
superior  maneuverability  and  kill  him.  In  an  air-to-ground  mission  requiring 
reaction  to  enemy  air  defenses,  speed  is  essential  for  the  same  reason;  a  lack  of 
speed  effectively  makes  an  aircraft  unable  to  defend  against  surface-to-air  fires. 
Similarly,  we  can  usually  slow  down  an  acquisition  process,  but  seldom  can  we 
speed  it  up  once  started.  Additionally,  if  we  do  not  maintain  the  speed  of  an 
acquisition  process,  producing  valued  systems  inside  our  adversaries’  loops, 
they — the  enemies  of  obsolescence  or  requirements  change — will  render  our 
product  value-less  and  the  program  will  eventually  fail. 

Continuing  the  aerial  combat  analogy,  as  an  additional  benefit,  speed 
increases  options.  With  a  sufficient  speed  advantage,  a  fighter  aircraft  has 
multiple  options  from  which  to  choose  that  translate  into  a  competitive 
advantage,  such  as  exchanging  knots  for  nose  position  to  employ  weapons  or 
converting  excess  kinetic  energy  into  potential  energy  by  climbing  to  establish  an 
altitude  sanctuary  from  which  to  attack  or  escape  an  opponent.  In  contrast,  with 
a  speed  disadvantage  an  aircraft  really  has  only  one  option:  try  to  increase 


7  This  logic  purposefully  over-simplifies  the  value  of  high  speed  in  an  ACM  engagement.  The 
author  recognizes  the  significance  of  cornering  speed  and  the  fact  that  an  offensive  aircraft  can 
easily  be  “too  fast”  in  some  situations  such  an  impending  overshoot.  The  author  also  recognizes 
the  value  in  other  situations  of  slow  speeds,  such  as  when  attempting  to  force  an  opponent’s 
overshoot. 
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kinetic  energy  by  descending  while  also  trying  to  stay  alive.  Similarly,  the  quicker 
we  provide  a  valued  capability  to  the  user,  the  more  rapidly  we  can  analyze  our 
new  situation  relative  to  the  enemy  (including  technological  opportunities  and 
operational  requirements),  capitalize  on  any  successes,  and  apply  them  to  our 
future  objectives,  effectively  shortening  our  cycle  time  while  providing  more 
options.  Alternatively,  a  prolonged  acquisition  process  only  has  one  option: 
continue  towards  long  term  and  perhaps  outdated  requirements  or  face 
termination. 

Accomplishing  our  objectives  requires  a  rapid  process,  whether  in  pursuit 
of  information  superiority,  in  a  dogfight,  or  in  acquisitions.  Intuitively,  possession 
of  a  faster  process  than  the  enemy  directly  contributes  to  successful  operations 
and  consistently  provides  more  options  from  which  to  choose.  Again,  the  bottom 
line:  Speed  increases  value. 

3.  Continual  Improvement 

Achieving  a  competitive  advantage  necessitates  continual  improvement, 
and  once  we  achieve  it,  sustaining  that  position  requires  the  same  consistent 
focus  on  continual  improvement.  In  an  effort  to  accomplish  this,  military  Services 
use  feedback  mechanisms  to  improve  upon  past  military  operations  in  the  form  of 
lessons  learned,  after  action  reports,  case  studies,  and  general  military  history. 
We  teach  and  study  such  documentation  in  an  effort  to  retain  and  convey  our 
predecessor’s  knowledge.  For  example,  the  Marine  Corps  has  recognized  the 
value  of  a  feedback  mechanism  through  the  creation  and  staffing  of  its  Center  for 
Lessons  Learned,  which  strives  to  capture  operational  experiences  in  an  effort  to 
improve  future  operations  and  exercises. 

Achieving  information  superiority  also  requires  a  feedback  mechanism  to 
support  continual  improvement.  This  mechanism  involves  validation  of  multiple 
facets  of  information  in  order  to  realign  future  actions  toward  an  end  goal.  This 
process  requires  an  established  methodology  to  capture  and  analyze  not  only 
previous  actions  taken,  but  also  the  effects  resulting  from  those  actions.  In  his 
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book,  Hyper-Beings,  Dr.  Hayes-Roth  emphasized  the  importance  of  an  effective 
feedback  mechanism  to  enable  adaptive  behavior  and  facilitate  improvement 
(Hayes-Roth,  2006).  Referencing  Figure  4,  the  last  step  of  his  eight-step 
superior  decision  loop  is  Validate  and  Improve  the  Model.  Although  the  model 
defines  it  as  the  last  step,  it  occurs  not  only  at  step  eight,  but  throughout  all  steps 
of  the  loop,  which  forms  the  essence  of  continual  improvement.  Applying  his 
model  to  the  achievement  of  information  superiority,  while  focusing  on  step  8,  we 
see  that  we  must  continually  validate  and  improve  upon  the  following  facets  of 
information: 

•  Which  information  provides  value 

•  How  we  get  that  information 

•  How  we  analyze  it 

•  How  we  use  it  to  change  our  behavior 

•  How  we  communicate  it 
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Figure  4. 


The  Superior  Decision  Loop  (From  Hayes-Roth) 


RVEA  must  similarly  incorporate  continual  improvement.  EA,  although  an 
acquisition  policy  improvement  as  defined  in  the  DoD  Instruction  5000,  does  not 
effectively  incorporate  feedback  or  focus  on  continual  improvement.  To  its  credit, 
it  mentions  spiral  development  in  which  we  develop  a  little,  test  a  little,  develop  a 
little  more,  test  a  little  more,  but  it  does  not  stress  the  importance  of  establishing 
a  methodology  to  improve  upon  each  spiral  over  time.  EA,  as  opposed  to  RVEA, 
does  not  necessarily  capitalize  on  what  works  and  kill  what  does  not.  Instead,  it 
takes  the  results  of  a  spiral  -  whether  successful  or  not  -  and  attempts  to  fix  it  or 
add  functionality  to  it,  inevitably  increasing  its  complexity  and  consequently 
decreasing  its  evolvability  (Sangwan,  Lin,  &  Neill,  2008).  In  order  to  keep  this 
complexity  in  check  and  continue  focusing  on  valued  improvements,  a  program 
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office  cannot  allow  a  casual  validation  and  improvement  process;  on  the 
contrary,  it  must  ensure  a  documented,  formal  methodology. 

Additionally,  EA  prematurely  plans  increments  and  spirals  in  a  system’s 
lifecycle.  For  instance,  it  illustrates  a  version  of  so-called  continual  improvement 
that  shows  three  planned  increments  over  fifteen  years  with  preplanned  product 
improvements  every  five  years.  This  is  too  scripted  and  inflexible!  A  program 
office  must  incorporate  a  more  responsive  process  that  captures  dynamic, 
constantly  moving  targets  and  quickly  provides  multiple  options  from  which  to 
choose,  implement,  and  improve  on. 

Furthermore,  lacking  such  a  process  that  incorporates  continual 
improvement  will,  sooner  or  later  (probably  sooner),  decrease  the  value  of  even 
the  most  valued  system  because  of  the  rate  of  change  of  requirements  and 
technology.  In  other  words,  as  the  operators  increasingly  value,  or  perhaps  more 
appropriately,  covet  systems  they  do  not  have,  their  current  system’s  relative 
value  decreases...  unless  we  continually  validate  and  improve  upon  the  current 
system.  As  mentioned  earlier,  users  value  current  technology  and  object  to  old 
technology. 


Similar  to  the  process  of  attaining  information  superiority,  an  acquisition 
process  that  incorporates  continual  improvement  must  strive  to  validate  and 
improve  different  aspects  of  the  process  as  well  as  the  product.  Unfortunately, 
the  DAS  encompasses  multiple  levels  of  a  large  hierarchical  organization  and 
one  cannot  overstate  its  complexity.  As  Dr.  Hayes-Roth  points  out  though, 

Regardless  of  how  many  levels  of  hierarchy,  all  intelligent  entities 
operating  in  dynamic  environments  have  to  adapt  their  behavior 
continuously  in  response  to  feedback.  The  entity  as  a  whole  uses  a 
decision  loop  to  do  this,  and  each  subordinate  entity  in  the 
hierarchy  uses  a  decision  loop  in  its  own  area  of  responsibility. 
(Hayes-Roth,  2006) 
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The  entities  could  be  as  large  as  our  National  Command  Authority  (NCA) 
that  sets  vision  and  strategy,  or  as  small  as  an  acquisition  program  office 
charged  with  implementing  an  acquisition  plan.  Improving  the  acquisition 
process  as  it  relates  to  the  NCA  is  not  the  purpose  of  this  thesis,  so  narrowing 
the  broad  scope  of  potential  areas  for  continual  improvement,  subordinate 
entities  such  as  the  program  office  and  program  manager  must  continually 
validate  and  improve  the  following  items  to  effect  continual  improvement: 

•  What  acquisition  items  provide  value 

•  How  we  develop  and  procure  them 

•  How  well  we  are  progressing  toward  providing  value 

•  How  we  should  change  our  behavior  to  improve  value  delivery 

Notice  the  emphasis  on  value  in  the  above  list  as  a  focal  point  for  continual 
improvement.  Once  we  implement  a  process  based  on  value,  we  will  become 
engaged  in  a  process  of  continuous  improvement  (Hayes-Roth,  Blais,  Pullen,  & 
Brutzman,  2008). 

Sometimes  our  validation  and  feedback  process  may  reveal  a  need  for  a 
significant  direction  change.  We  cannot  fear  such  change  and  we  must  address 
it  forthrightly.  For  example,  an  environmental  change  may  completely  invalidate 
a  requirement  for  a  system,  and  the  program  may  require  termination.  In  order  to 
effectively  implement  continual  improvement,  the  acquisition  process  cannot  shy 
away  from  such  change  or  fear  writing  off  sunk  costs.  It  benefits  all  stakeholders 
to  stop  development  of  an  unwarranted  system  instead  of  continuing  to  mount 
expenses  through  the  unnecessary  production,  fielding  and  support  of  such  a 
system.  According  to  the  GAO,  sunk  costs  should  not  drive  the  decision  to 
continue  a  program  (GAO-08-379,  2008).  Continual  improvement  means  making 
occasionally  tough  but  intelligent  decisions.  Although  these  decisions  may 
sometimes  displease  certain  stakeholders,  an  effective  acquisition  process 
hinges  on  them  to  a  large  degree. 
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Finally,  two  caveats  relating  to  continual  improvement  deserve  attention. 
First,  an  effective  process  of  continual  improvement  does  not  warrant  setting 
unjustified  or  haphazard  strategic  targets  simply  because  of  the  ability  to  improve 
upon  them  later.  Initial  goal  setting  requires  deliberately  calculated,  insightfully 
visionary,  and  ambitious  but  feasible  targets.  An  organization  cannot 
overemphasize  the  importance  of  this  step.  The  existence  of  an  effective 
feedback  loop  and  improvement  method  should  not  serve  as  an  insurance  policy 
or  safety  net  for  bad  strategic  decisions.  Second,  continual  improvement  does 
not  mean  continual  change.  An  organization  with  an  effective  method  of 
accomplishing  continual  improvement  should  not  consequently  encourage 
continual  change.  On  the  contrary,  an  effectively  planned  vision,  strategy  and 
policy  should  minimize  the  frequency  of  major  changes...  even  in  the  name  of 
continual  improvement. 

To  summarize,  rapid,  value-based,  evolutionary  acquisition’s  foundation 
rests  on  the  principle  of  quickly  providing  user-defined  value  in  rapid  succession 
while  focusing  on  continual  improvement.  These  three  traits — rapid,  value- 
based,  and  continual  improvement — form  the  basis  of  an  effective  acquisition 
process.  The  actual  implementation  of  RVEA  includes  the  same  phases  as 
contained  in  the  DoD’s  instruction  for  the  operation  of  the  DAS  and  aligns  with 
that  regulatory  document.  The  next  section  details  the  specific  actions  and 
intents  of  RVEA  throughout  each  DAS  phase. 

C.  THE  OPERATION  OF  RVEA 

With  the  firm  establishment  of  a  conceptual  foundation  of  rapid,  value- 
based  evolutionary  acquisition,  this  section  will  concentrate  on  its  tangible 
application.  It  strives  to  avoid  abstractions,  difficult  to  implement  in  the  real  world 
of  acquisitions,  and  instead  focuses  on  pragmatic,  readily  executable 
recommendations  for  a  Program  Management  Office  (PMO)  or  Program 
Executive  Office  action  officer...  where  the  proverbial  rubber  meets  the  road. 
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1. 


Introduction 


This  section  briefly  describes  the  underlying  assumptions  and  constraints 
of  the  application  of  RVEA.  Additionally,  it  includes  descriptions  of  the  most 
applicable  documents  that  govern  the  defense  information  systems  acquisition 
process. 


a.  Assumptions  and  Constraints 

Government  policies  and  regulations  naturally  resist  change.  Even 
if  an  established  rule  obviously  and  admittedly  needs  change,  rescinding  or 
modifying  it  presents  quite  a  challenge.  For  example,  the  DoDI  5000  took  years 
to  update,  and  when  the  Defense  Department  finally  published  the  revision  in 
December  2008,  it  included  surprisingly  minimal  changes,  considering  the  time 
required  for  revision.  This  thesis  therefore  does  not  suggest  improving  the 
acquisition  process  through  changes  in  acquisition  policy.  Such  change  would 
take  too  long,  and  whether  the  regulations  need  major  revision  is  actually 
debatable.  The  process  needs  help  now,  and  any  improvement  must  operate 
under  the  constraints  of  all  currently  applicable  regulations,  directives,  and 
instructions. 

The  prescription  to  heal  the  problems  with  the  DAS  implies 
widespread  cultural  change,  but  one  cannot  realistically  believe  any  single 
person  or  organization  could  implement  a  DoD-wide  or  even  Service-wide  culture 
shift  with  the  urgency  required.  The  culture  of  government  and  DoD  acquisitions, 
deeply  rooted  in  stove-piped,  I’ve-got-mine  mentalities  and  self-promoting,  get- 
your-own  rice-bowls,  will  not  change  overnight.  However,  breaking  these  bad 
habits  and  the  desired  broad  cultural  change  begins  with  individuals  and  their 
successes,  which  eventually  spread  throughout  organizations,  resulting  in  the 
desired  change.  This  change  can  and  must  begin  with  the  individual  action 
officers  of  acquisition  programs.  In  the  words  of  Gandhi,  “You  must  be  the 
change  you  wish  to  see  in  the  world.” 
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b.  Governing  Documents 

The  phrase  “governing  documents”  encompasses  numerous 
statutory  and  regulatory  items  which  control  the  DoD  acquisition  process.  Some 
of  these  items  include  Instructions  and  Directions,  the  Federal  Acquisition 
Regulation  (FAR),  and  various  laws  such  as  the  Information  Technology 
Management  Reform  Act  of  1996  (aka  the  Clinger-Cohen  Act  or  CCA).  These 
documents  define  the  rules  of  the  acquisition  process.  The  subsections  below 
briefly  describe  some  of  the  Defense  acquisition’s  primary  governing  documents 
for  information  systems  in  order  to  first  provide  the  reader  an  appreciation  for  the 
rules  under  which  acquisition  action  officers  must  operate,  and  second  to  point 
out  some  of  the  encouraging,  positive  aspects  of  these  documents.  Additionally, 
the  description  of  the  DoDI  5000.02  will  lay  a  framework  for  the  subsequent 
discussion  of  the  application  of  RVEA. 

(1)  DoDI  5000.02  -  Operation  of  the  Defense  Acquisition 
System.  The  DoDI  5000.02  establishes 

a  simplified  and  flexible  management  framework  for  translating 
capability  needs  and  technology  opportunities,  based  on  approved 
capability  needs,  into  stable,  affordable,  and  well-managed 
acquisition  programs.  (DoDI  5000.02,  2008) 

The  document’s  basis  lies  in  governance-by-exception 
where,  unless  specifically  prohibited,  an  action  is  allowed  as  long  as  it  proves 
itself  appropriate,  justified  and  does  not  violate  another  regulation.  This 
encourages  innovation  and  attempts  to  avoid  stifling  so-called  thinking  out  of  the 
box.  The  instruction  discourages  the  application  of  additional  restrictions  from 
the  DoD  Services  and  Components  and  allows  waivers  to  its  guidelines  unless 
prohibited  by  statute.  It  provides  lists  of  all  statutory  and  regulatory  requirements 
for  the  lifecycle  of  an  acquisition  program,  and  contains  sections  which  describe 
Acquisition  Categories  and  determination  of  Milestone  Decision  Authority,  IT 
considerations,  Systems  Engineering,  Resource  Estimation,  as  well  as  other 
subjects  directly  pertaining  to  defense  acquisitions. 
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The  first  part  of  the  instruction,  divided  into  applicable 
sections,  details  the  procedures  of  the  phases  of  the  acquisition  process  as 
depicted  in  Figure  5.  Material  Solution  Analysis  (aka  Pre-Milestone  A), 
Technology  Development,  Engineering  and  Manufacturing  Development  (EMD), 
Production  and  Deployment,  and  Operations  and  Support  comprise  the  phases 
of  defense  acquisition  and  typically  describe  the  life-cycle  phase  of  a  program. 
Notice,  however,  the  three  broad  phases  in  the  lower  portion  of  the  diagram: 
Pre-System  Acquisition,  System  Acquisition,  and  Sustainment.  These  will  serve 
as  categories  for  the  application  of  RVEA  in  subsequent  sections. 
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Figure  5.  The  Defense  Acquisition  Management  System  (From  DoDI 

5000.02) 


(2)  Federal  Acquisition  Regulations  System.  The 
government  established  the  Federal  Acquisition  Regulations  System  for  the 
codification  and  publication  of  uniform  policies  and  procedures  for  acquisition  by 
all  executive  agencies  of  the  U.S.  Government,  and  the  FAR  is  the  primary 
document  of  the  system.  An  enormous  document  with  Volume  1  stretching  to 
almost  2,000  pages,  the  FAR,  not  unlike  the  DoDI  5000.02,  takes  a  govern-by- 
exception  approach.  It  provides  regulatory  guidance  for  the  purchase  of  products 
and  services,  and  most  of  its  parts  contain  at  least  some  applicability  to  systems 
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acquisitions.  In  the  context  of  this  thesis  however,  only  certain  parts  of  the  FAR 
will  be  mentioned,  particularly  Parts  1,  7,  12,  13,  34,  and  39.  The  paragraphs 
below  paraphrase  these  specific  FAR  parts  relevant  to  this  thesis  (Federal 
Acquisition  Regulation,  2005).  Notice  the  bold  italicized  words  (formatting  added 
for  emphasis). 

-  Part  1  -  Federal  Acquisition  Regulations  System.  If  a 
particular  strategy  or  practice  is  neither  specifically  addressed  in  the  FAR  nor 
prohibited  by  law  members  should  not  assume  it  is  prohibited.  Rather,  teams 
should  interpret  absence  of  direction  as  permitting  innovation. 

-  Part  7  -  Acquisition  Planning.  Agencies  shall  perform 
acquisition  planning  and  conduct  market  research  for  all  acquisitions  in  order  to 
promote  and  provide  for  acquisition  of  commercial  items  and  for  full  and  open 
competition  to  the  maximum  extent  practicable. 

-  Part  12  -  Acquisition  of  Commercial  Items.  Agencies  shall 
acquire  commercial  items  or  nondevelopmental  items  if  available  to  meet  the 
needs  of  the  agency. 

-  Part  13  -  Simplified  Acquisition  Procedures.  Prescribes 
simplified  acquisition  procedures  in  order  to  reduce  administrative  costs, 
promote  efficiency  and  economy  in  contracting,  and  avoid  unnecessary 
burdens  for  agencies  and  contractors. 

-  Part  34  -  Major  Systems  Acquisition.  Ensures  agencies 
acquire  major  systems  in  the  most  effective,  economical,  and  timely  manner. 
Agencies  acquiring  major  systems  shall  promote  innovation  and  full  and  open 
competition  and  sustain  effective  competition  between  alternative  system 
concepts  and  sources  for  as  long  as  it  remains  beneficial. 

-  Part  39  -  Acquisition  of  Information  Technology.  When 
developing  an  acquisition  strategy,  contracting  officers  should  consider  the 
rapidly  changing  nature  of  information  technology  through  market  research 
and  the  application  of  technology  refreshment  techniques.  (Note  that  as  National 
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Security  Systems,  most  DoD  systems  would  fall  under  Title  40  United  States 
Code,  Section  1 1 302,  instead  of  the  FAR  Part  39.) 


Considering  the  phrases  emphasized  above,  the  FAR 
means  well  and  encourages  innovation,  efficiency,  and  rapidity.  RVEA  embraces 
these  characteristics  and  brings  them  to  the  forefront  of  acquisition  as 
measurable  qualities. 

(3)  Clinger-Cohen  Act.  The  CCA  mandated  the 

establishment  of  goals  for  improving  the  efficiency  and  effectiveness  of  agency 
operations  through  the  effective  use  of  IT.  Additionally,  the  CCA  sought  to 
prescribe  performance  measurements  for  executive  agency  IT  and  ensure  these 
performance  measurements  determine  how  well  the  IT  supports  agency 
programs  (The  National  Defense  Authorization  Act,  1996). 

Having  briefly  described  some  of  the  documents  governing 
the  acquisition  process,  the  next  section  will  prescribe  recommended 
improvements  for  the  process  using  RVEA  within  the  bounds  of  these 
documents. 

2.  Operation  of  RVEA 

Although  the  DoDI  5000.02  defines  the  commonly  referred  to  phases  of 
the  acquisition  process  from  Pre-Milestone  A  to  Operations  and  Support,  this 
section  employs  the  broader  activity  phases  of  Pre-System  Acquisition,  System 
Acquisition,  and  Sustainment  to  describe  the  specifics  of  RVEA. 

a.  Pre-System  Acquisition 

Many  tasks  and  activities  must  be  accomplished  prior  to  the  start  of 
a  new  acquisition  program  of  record,  and  many  do  not  directly  involve  acquisition 
action  officers,  per  se,  because  of  the  top-down  nature  of  the  requirements 
generation  system  called  JCIDS  (reference  Figure  6  below).  Through  the  JCIDS 
process,  top-level  military  officers  of  the  Joint  Requirements  Oversight  Council 

(JROC)  identify  capabilities  required  to  support  national  strategies  such  as  the 
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National  Defense  and  National  Military  Strategies.  Specifically,  the  JROC 
identifies  (1)  the  capabilities  and  operational  performance  criteria  required  to 
execute  missions  successfully;  (2)  the  shortfalls  in  existing  systems  to  deliver 
those  capabilities  and  the  associated  operational  risks;  and  (3)  the  possible 
solution  space  for  the  capability  shortfalls.  This  process  supports  acquisition  by 
providing  validated  capability  needs  and  associated  performance  criteria  as  a 
basis  for  acquiring  the  right  systems,  and  it  provides  prioritization  and 
affordability  advice  (CJCSI  31 70.01  F,  2007).  For  the  purposes  of  this  discussion 
on  Pre-System  Acquisition,  we  will  assume  the  JCIDS  process  has  first 
determined  a  valid  requirement  for  a  materiel  solution  to  fill  a  capability  gap,  and 
second,  has  ruled  out  all  non-materiel  solutions. 
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Figure  6.  High-level  View  of  JCIDS  (From  CJCSI  3170.01F) 
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Because  of  the  long-range  nature  of  national  strategies,  the 
capabilities  and  technologies  required  to  achieve  these  distant  targets  similarly 
only  exist  in  the  distant  future.  Reflecting  back  on  the  discussion  of  setting  near- 
term  goals  for  capability  improvement  (Figure  3.  ),  a  program  should  hit  the 

target,  or  achieve  the  desired  capability  within  two  years  if  at  all  possible.  This 
does  not  suggest  the  JCIDS  process  should  stop  identifying  long-range  strategic 
capability  gaps  using  its  top-down  requirements  generation.  On  the  contrary,  a 
coordinated  and  integrated  effort  across  the  DoD  necessitates  the  top-down 
process  in  its  support  of  national  strategy.  But  once  a  capability  gap  and  an 
appropriate  materiel  solution  are  identified,  the  assigned  program  manager 
should  develop  an  acquisition  strategy  that  strives  to  satisfy  the  most  valued 
portions  of  the  requirement  in  rapid,  short  incremental  improvements  as  opposed 
to  attempting  to  fill  100%  of  the  gap  through  a  prolonged  development  phase. 
Case  in  point:  the  Joint  Strike  Fighter  (GAO-06-110,  2006).  Instead  of  trying  to 
provide  a  new  airframe  with  all  new  capabilities  and  improvements  across 
multiple  venues,  it  should  have  focused  on  providing  the  most  valuable,  most 
needed  capabilities  first.  In  other  words,  if  the  highest  priority  capability 
hypothetically  focused  on  a  stealthy  airframe  to  replace  the  aging  F/A-18,  AV-8B, 
and  F-16  aircraft,  then  to  the  maximum  extent  possible,  it  should  have 
concentrated  on  providing  just  the  airframe  as  quickly  as  possible  while  reusing 
preexisting,  non-developmental  items  to  accomplish  other  functions  as  long  as  it 
remained  beneficial  to  do  so.  If  at  the  time,  opportunities  existed  to  grab  other 
low-hanging  fruit  (mature,  demonstrated  and  affordable  technology 
improvements)  such  as  a  more  capable  radar,  targeting  system,  or  data  link,  then 
by  all  means,  the  program  rightfully  should  include  those  upgraded  components 
in  the  first  increment  with  the  new  airframe.  But  if  those  items  forced  delivery 
delays  of  the  highest  priority  capability,  i.e. ,  the  airframe,  the  program  office 
should  have  pushed  them  to  future  increments.  This  would  assist  in  fulfilling  the 
requirement  for  rapid  delivery  of  a  high-value  capability  improvement. 
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If  a  technology  falls  short  in  availability  or  maturity  which 
consequently  prohibits  its  use  to  fill  a  valid  requirement,  the  science  and 
technology  (S&T)  field  should  justifiably  assume  the  responsibility  of  developing 
and  maturing  that  technology.  It  should  not  transition  to  an  acquisition  program 
of  record  (again  reference  Figure  6.  above).  Furthermore,  development  of  any 
immature  technologies  by  S&T  should  take  an  evolutionary,  survival  of  the  fittest 
approach  to  determine  successes.  Preferably  using  commercial-off-the-shelf 
(COTS)  technology,  this  approach  should  investigate  as  many  parallel  competing 
alternatives  as  possible  to  satisfy  the  requirement  and  quickly  determine  which 
ones  succeed  and  which  ones  fail.  The  process  should  then  capitalize  on  the 
successful  options  and  continue  the  cycle,  modeling  the  technology’s 
development  after  the  previously  discussed  Superior  Decision  Loop  in  order  to 
provide  continual  improvement  to  not  only  the  product,  but  also  the  process. 
(Acquisition  programs  of  record  cannot  accommodate  this  type  of  developmental 
approach  which  investigates  multiple  options  at  a  rapid  rate  because  of  the  fiscal 
and  programmatic  constraints  under  which  they  operate.)  Once  a  technology 
demonstrates  military  utility  and  an  ability  to  satisfy  a  valid  operational 
requirement  in  S&T  though,  it  should  quickly  transition  to  an  acquisition  program 
office  to  confirm  and/or  improve  upon  its  operational  suitability  and  to  develop 
production  plans.  Indeed,  the  Pre-System  Acquisition  efforts  of  an  acquisition 
program  office  should  focus  on  ensuring  the  suitability  of  readily  available, 
demonstrated  technologies  for  military  use  and  move  away  from  prolonged 
development  of  transformational  or  revolutionary  products  which  attempt  major 
capability  leaps.  This  will  keep  programs  from  experiencing  predictable  delays  of 
unpredictable  duration. 

In  the  Pre-System  Acquisition  phase,  following  identification  of  a 
requirement  for  a  materiel  solution  to  fill  a  capability  gap,  activities  must  involve 
the  end  user  in  order  to  help  guarantee  the  value  basis  of  the  acquisition.  As 
described  previously,  the  user  stakeholder  defines  the  value  that  helps  ensure 
program  success.  The  activities  of  this  phase  requiring  user  involvement  include 
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program  reviews  such  as  the  System  Requirements  Review  which  succinctly 
define  the  operational  requirements,  including  Key  Performance  Parameters 
(KPP),  Key  System  Attributes  (KSA),  and  system  specifications,  among  others. 

Excellent  acquisition  action  officers  prove  their  worth  at  these 
program  meetings  because  when  user  representatives  help  define  a  system’s 
requirements,  they  often  neglect  to  specify  things  they  consider  common  sense 
due  to  a  culture  barrier  between  them  and  the  developers.  For  instance, 
reflecting  back  on  TLDHS,  the  users  who  helped  define  the  initial  operational 
requirements  for  the  system  may  have  never  thought  they  had  to  explicitly 
specify  the  system’s  usability  in  direct  sunlight,  and  the  early  developers  could 
have  easily  neglected  to  test  the  beta  system  anywhere  except  in  sterile 
conditions.  An  acquisition  action  officer  must  anticipate  challenges  such  as 
these  and  bridge  the  culture  gap  between  the  system  designers/engineers  and 
the  users  to  ensure  that  all  significant  assumptions  become  explicit  and  no 
requirement  stones  remain  unturned. 

Additionally,  operators  and  developers  of  a  system  do  not 
necessarily  speak  the  same  language  (figuratively  speaking)  and  an  action 
officer  must  sometimes  serve  as  an  interpreter  in  defining  and  prioritizing  a 
system’s  quality  aspects — usability,  reliability,  availability,  maintainability, 
transportability,  etc.  Using  a  clearly  defined  and  prioritized  list  of  quality 
attributes  based  upon  user  inputs  and  understood  by  managers  and  developers, 
these  three  different  stakeholders  can  identify  tradeoff  points  and  select  the 
system  functions  providing  the  biggest  bang  for  the  buck.  This  prioritized  list  of 
functions  and  attributes  will  serve  as  a  basis  for  the  program’s  plan  for 
incremental  improvements.  User  involvement  helps  ensure  the  value-basis  of  a 
system,  and  proactive  acquisition  action  officers  augment  the  meaningfulness, 
clarity,  and  thoroughness  of  the  user’s  inputs  and  help  prioritize  among  many 
potential  valued  features. 
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The  responsibilities  of  an  acquisition  action  officer  do  not  end  there. 
He  or  she  must  define  a  means  to  measure  the  above  qualities  of  the  acquisition 
process,  because,  in  the  words  of  Drucker,  you  get  what  you  measure  (Drucker, 
2001).  Measures  of  effectiveness  (MOEs)  have  historically  seen  use  as 
performance  metrics  of  systems  or  products,  but  in  RVEA,  program  offices  must 
measure  not  only  aspects  of  the  product,  but  also  the  acquisition  process  itself. 
Some  attributes  of  the  process  such  as  time  to  value  (rapidity)  are  relatively 
straightforward  to  measure.  Others,  such  as  value  and  continual  improvement, 
are  more  abstract  and  potentially  subjective  and  therefore  benefit  from 
managerial  insight  and  expertise. 

Arguably,  the  value  of  the  acquisition  process  directly  relates  to  the 
user-defined  value  of  the  end  product.  An  action  officer  has  the  means  at  his  or 
her  disposal  to  measure  product  value.  The  simplest  of  these  merely  tests  the 
ability  of  the  system  to  meet  the  defined  operational  requirements,  usually  in  the 
form  of  KPPs  and  KSAs.  Assuming  the  validity  and  currency  of  the  system’s 
requirements,  developmental  test  and  evaluation  and  operational  test  and 
evaluation  (OT&E)  measure  a  system’s  performance  in  terms  of  reliability, 
maintainability,  speed,  and  so  forth.  They  consequently  also  measure  the  value 
of  the  acquisition  process  to  a  limited  extent.  An  action  officer  should  not, 
however,  blindly  assume  the  currency  and  validity  of  the  system’s  requirements. 
He  or  she  should  formally  and  informally  survey  user  representatives  throughout 
the  acquisition  phases  to  reaffirm  the  value  of  the  product  and  process.  A  formal 
survey  should  allow  the  user  representatives  to  quantifiably  answer  (for  instance, 
on  a  scale  of  1  to  10)  questions  such  as: 

•  If  the  system  meets  all  operational  requirements,  what  is  the 
likelihood  you  would  use  it  for  its  intended  mission? 

•  How  many  alternatives  can  you  think  of  for  accomplishing 
the  system’s  mission?  How  many  of  those  alternatives 
would  you  more  likely  use  instead  of  the  system? 
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•  How  adequate  do  you  consider  the  planned  delivery 
timeline? 

•  How  much  value  do  you  think  the  planned  follow  on  system 
increment(s)  will  add? 

Such  formal  surveys  can  succumb  to  the  dangers  of  subjective 
biases  and  preconceived  notions  from  the  users  though.  Therefore,  in  order  to 
qualify  survey  results,  informal,  non-retribution  discussions  between  the  users 
and  the  action  officers  about  the  system  and  its  capabilities  should  supplement 
formal  surveys.  To  narrow  the  culture  gap  and  assist  in  cross  pollination 
between  developers  and  users,  open  discussions,  preferably  between  these 
uniformed  military  members  (users  and  action  officers),  will  help  determine  the 
reliability  of  formal  surveys.  Such  discussions  will  capitalize  on  an  unspoken 
trust  between  uniformed  members  and  help  circumvent  the  military’s  unfortunate 
but  often  present  distrust  of  contractors.  Additionally,  an  acquisition  action 
officer  should  poll  as  many  user  representatives  as  possible  to  increase  the 
reliability  of  such  surveys.  Although  these  surveys  will  not  necessarily  pinpoint 
problems  in  specific  system  requirements,  they  will  give  a  program  office  an 
overall  idea  of  the  value  the  operators  place  on  the  system.  Surveys  that  reveal 
a  widespread  lack  of  user  value  for  a  product  highlight  problems  for  not  only  the 
system  under  development,  but  also  the  potentially  broken  process  as  well. 

Surveys  can  help  subjectively  measure  the  performance  of  the 
acquisition  process,  but  program  offices  should  strive  to  take  a  more  objective 
approach  as  well.  Objectively  measuring  an  acquisition  process’s  ability  to 
provide  continual,  valued  improvement  does  not  occur  easily,  but  Chris 
Gunderson  and  others  at  the  World  Wide  Consortium  for  the  Grid  (W2COG) 
have  taken  a  systematic,  objective  approach  and  devised  algorithms  for 
measuring  not  only  the  value  basis  of  an  acquisition  process,  but  also  its  ability  to 
provide  continual  improvement.  Similar  to  the  way  the  KPP  of  Operational 
Availability  (A0)  measures  reliability  or  Ouality  of  Service  (CoS)  by  dividing 
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successful  operating  time  by  total  time  to  give  a  percent  value,8  their  first 
algorithm  conceptually  compares  the  amount  of  valued  information  delivered  by 
the  system  and  available  to  its  users  against  the  amount  of  total  information 
delivered  or  processed  (reference  Table  1.  below).  This  formula  equates  to 
Information  Value  Availability,  or  AjV,  a  system-level  MOE,  and  measures  Value 
of  Service  (VoS)  in  terms  of  the  information  a  system  delivers/processes.  The 
next  algorithm  factors  time  into  the  equation  by  determining  Net-Ready 
Availability  (Anr).  Anr,  a  process-level  metric,  measures  Value  of  Enhancement 
(VoE)  by  calculating  how  well  the  process  continually  delivers  valued 
enhancements  to  the  system,  taking  into  account  the  process’s  originally 
estimated  and  current  build-time  performance.9  In  summary,  these  metrics 
effectively  and  objectively  measure  how  much  value  each  increment  adds  to  the 
process  (Gunderson,  Minton,  &  Hayes-Roth,  2009). 


System  Reliability 

A0=  Successful  operating  time  /  Total  time 

Value  of  Service 

Aiv=  Available  valued  bits  /  Total  bits  processed 

Value  of  Enhancement 

Anr =  Initial  estimated  development  time 

Capability  deployment  time 

Table  1.  Conceptual  Reliability,  VoS,  and  VoE  Algorithms 


The  numerous  Pre-System  Acquisition  activities  lay  the  framework 
for  a  program’s  future  and,  if  accomplished  in  a  manner  consistent  with  the 
principles  of  RVEA,  they  can  increase  the  probability  of  a  program’s  success. 
The  processes  of  this  phase,  including  but  not  limited  to  requirements 
generation,  technology  development  and  establishment  of  an  acquisition 
strategy,  must  focus  on  rapidity,  stand  on  user-defined  value,  and  ensure 

8  This  admittedly  oversimplifies  the  operational  availability  algorithm  and  the  author 
recognizes  that  Ao  employs  Mean  Time  Between  Failure  (MTBF),  Mean  Time  to  Repair  (MTTR), 
and  Mean  Logistics  Delay  Time  (MLDT),  such  that:  Ao  =  MTBF/(MTBF+MTTR+MLDT). 

9  Gunderson,  et  at.,  have  done  extensively  detailed  analysis  to  capture  the  value-added 
performance  of  the  acquisition  process  objectively  in  terms  of  time-to-capability  and  value  of 
service,  and  the  algorithms  described  here  are  purposefully  kept  at  a  conceptual  level.  As  of  this 
writing,  their  analysis  was  still  ongoing,  and  this  conceptual  description  is  only  a  sampling  of  their 
efforts  but  sufficient  for  the  purposes  of  this  thesis. 
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continual  improvement.  Furthermore,  these  qualities  must  translate  into 
measurable  quantities  that  provide  meaning  to  an  acquisition  program  office. 
Successfully  accomplishing  these  objectives  in  a  program’s  infancy  will  help 
ensure  continued  success  in  subsequent  acquisition  phases. 

b.  System  Acquisition 

System  Acquisition  technically  begins  with  a  program’s  approval  of 
Milestone  B  and  its  subsequent  entrance  into  the  EMD  phase  (reference  Figure  5 
above).  The  DoDI  5000.02  emphasizes  the  importance  of  demonstrating  a 
potential  solution’s  critical  technical  elements  (CTEs)  in  a  relevant  environment 
before  considering  the  solution  a  viable  alternative.  It  further  states  that  a 
technology’s  maturity  shall  determine  the  path  through  EMD  (DoDI  5000.02, 
2008).  Within  this  statement  lies  a  program’s  ability  to  accomplish  rapid 
acquisition  of  a  capability  and  quickly  provide  value  to  the  user:  “...a 
technology’s  demonstration  in  a  relevant  environment  and  its  level  of  maturity...” 

An  acquisition  program’s  ability  to  complete  the  EMD  phase  rapidly 
depends  on  the  level  of  readiness  or  maturity  of  the  proposed  technology.  Given 
a  demonstrated,  proven  technology,  the  primary  engineering  effort  of  this  phase 
should  be  limited  to  systems  integration,  including  bundling  of  capabilities  and 
functions,  and  production  or  manufacturing  preparation.  Unfortunately,  many 
programs  successfully  meet  the  exit  criteria  of  the  Pre-System  Acquisition 
Technology  Development  phase  while  still  immature,  with  major  engineering  and 
development  efforts  remaining.  But  how  is  this  possible  considering  the  criteria 
to  exit  the  phase  and  enter  EMD,  which  state  that,  among  other  things,  a 
potential  solution  must  demonstrate  its  technology  in  a  relevant  environment? 
Similar  to  the  aforementioned  GAO  findings  of  optimistic  cost  and  schedule 
estimates  leading  to  problems,  acquisition  programs  and  commercial  vendors 
can  take  the  optimistic  route  and  purposefully  decrease  the  rigor  of 
demonstrations  or  the  relevancy  of  the  environment  in  order  to  “pass” 
Technology  Development  and  enter  EMD.  This  has  the  effect  of  making  the 
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technology  appear  more  mature  than  it  actually  is  -  a  fact  that  sometimes 
materializes  months  or  years  later  when  schedules  have  slipped  and  cost 
estimates  have  escalated.  To  avoid  this  predicament  of  getting  bogged  down  in 
EMD,  the  acquisition  action  officer  must  remain  true  to  the  warfighter  and  require 
rigorous  and  valid  early  demonstrations  of  the  CTEs.  Relevant  demonstrations 
not  only  help  expedite  completion  of  EMD,  but  they  also  can  factor  into  MOEs 
that  will  help  a  PMO  objectively  determine  a  system’s  ability  to  provide  value. 

Excessive  optimism  and  subjective  measurements  of  a 
technology’s  maturity  can  ultimately  lead  to  schedule  delays,  whereas  stressing 
valid  technological  maturity  has  the  potential  to  increase  acquisition’s  speed  and 
success  rate.  Objective  MOEs  again  come  into  play  here  as  a  system  proceeds 
through  the  EMD  phase  in  preparation  for  eventual  operational  testing, 
production  and  deployment.  Applying  algorithms  such  as  those  for  VoS  and  VoE 
above  will  help  enable  a  program  office  to  measure  the  maturity  and  value  of  a 
technology  as  it  attempts  transition  from  Pre-System  Acquisition  to  System 
Acquisition.  Furthermore,  to  maintain  awareness  of  the  validity  of  the  product 
and  the  effectiveness  of  the  process,  a  program  office  should  routinely  apply  the 
algorithms  until  its  official  requirements  document  formally  adopts  them  as  part  of 
a  system’s  KPPs  or  KSAs. 

A  program  typically  completes  its  Preliminary  Design  Review  (PDR) 
and  Critical  Design  Review  (CDR)  in  the  System  Acquisition  phase  (although 
sometimes  it  may  complete  PDR  in  the  Pre-System  Acquisition  phase),  and 
emphasis  on  these  reviews  has  increased  in  the  latest  update  to  the  DoDI 
5000.02.  Such  reviews  formally  establish  and  confirm  a  system’s  underlying 
architecture.  Correctly  designed,  the  system  architecture  should  promote 
continual  improvement  through  an  evolvable,  flexible  and  open  framework  that 
will  readily  accept  rapidly  changing  components.  Additionally,  the  architecture 
framework  should  shy  away  from  proprietary  capabilities  and  components  and 
instead  concentrate  on  commonality,  which  will  encourage  reusability  and  agility. 
These  features  will  pay  dividends  when  developing  the  manufacturing  process, 
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when  requirements  change,  and  when  future  increments  take  shape. 
Furthermore,  they  promote  continual  improvement  and  should  be  built  into  a 
system  from  day  one,  upon  initial  architecture  definition.  Assuming  a  program 
has  intelligently  designed  its  system  architecture  which  is  formalized  at  PDR  and 
confirmed  at  CDR,  it  should  possess  an  inherent  ability  to  continually  improve 
upon  the  product. 

The  PDR  and  CDR  also  can  help  a  program  sustain  its  value  basis. 
Similar  to  the  activities  of  requirements  definition  and  Pre-System  Acquisition,  the 
source  of  this  value  stems  not  surprisingly  from  user  involvement.  The  DoDI 
5000.02  calls  for  the  presence  of  user  representatives  at  the  PDR,  but  does  not 
explicitly  require  their  involvement  at  the  CDR.  Programs  can  and  occasionally 
do  get  side-tracked  in  development  between  PDR  and  CDR  and  as  a  result 
sometimes  seem  to  confuse  system  priorities,  which  is  another  reason  an 
acquisition  action  officer  should  never  blindly  assume  the  currency  or  validity  of  a 
system’s  requirements.  He  or  she  should  constantly  strive  to  gather  user  inputs 
at  not  only  these  formal  reviews,  but  also  user  events  such  as  OT&E  and  Live 
Fire  Test  and  Evaluation.  User  input  is  essential  at  PDR,  CDR  and  throughout 
the  System  Acquisition  phase  and  into  the  Sustainment  phase.  The  acquisition 
action  officer  cannot  depend  on  the  users  to  provide  such  input;  instead,  he  or 
she  must  proactively  seek  it. 

One  word  of  caution  though:  a  program  should  not  chase  a  user’s 
rapidly  changing  requirements.  Admittedly,  the  requirements  target  will  always 
change  or  move  somewhat,  but  program  success  requires  at  least  relative 
requirements  stability.  Reflecting  back  on  the  enemies  of  obsolescence  and 
changing  requirements,  “relative”  stability  means  the  time-to-capability  must  fall 
inside  the  time  it  takes  the  users  to  significantly  change  requirements.  Even 
though  the  user  community’s  desires  or  needs  may  have  shifted  slightly  through 
a  system’s  development,  if  a  program  maintains  an  ability  to  provide  a  valid 
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product  or  capability  in  a  short  timeframe,  e.g.,  inside  the  internal  enemy’s  loop, 
the  user  will  probably  value  the  system,  despite  the  slight  change  in 
requirements. 

Unfortunately,  the  DoD  regulations  consider  a  “short  timeframe” 
equal  to  about  five  years  for  a  weapon  system  (DoDI  5000.02,  2008),  which  is  an 
unacceptable  amount  of  time.  Technology  and  user  needs  could  easily  change 
drastically  in  five  years.  For  instance,  imagine  user  involvement  at  a  CDR  for  an 
IT  program  after  five  plus  years  of  development,  trying  to  satisfy  roughly  seven 
year  old  requirements.  Two  possible  outcomes  of  user  involvement  in  such  a 
slow  process  will  transpire:  either  (1)  the  users  will  deem  the  requirement  still 
valid,  and  they  will  walk  away  disgruntled  because  of  the  incomprehensible 
schedule  delays  in  the  program,  or  (2)  the  now  invalid  requirement  will  cause  the 
user  to  not  understand  why  the  program  continues  unnecessarily  wasting  money 
and  time  on  the  system.  Either  way,  the  results  increase  the  operating  force’s 
distaste  for  the  acquisition  process  and  reemphasize  the  need  for  rapidity  and 
continual  focus  on  user-defined  value  through  the  System  Acquisition  phase. 

c.  Sustainment 

As  the  acquisition  process  winds  down  into  the  Sustainment  phase 
and  a  system  nears  apparent  completion,  one  might  think  the  ability  of  a  PMO  to 
influence  the  process  through  RVEA  also  comes  to  a  halt.  However,  this  could 
not  be  further  from  the  truth.  The  entire  RVEA  process  emphasizes  continual 
consciousness  of  value  and  improvement,  but  the  Sustainment  phase  possesses 
the  most  logical  mechanism  for  continuing  value-addition  and  improvement  in 
rapid  fashion.  The  owners  of  the  newly  fielded  systems  have  an  opinion  of  the 
product  and  the  process,  and  the  program  office  merely  has  to  capture  this  input 
and  incorporate  appropriate  changes. 

In  the  Sustainment  phase,  systems  roll  off  the  production  line  and 
eventually  land  in  the  hands  of  users  in  operational  units.  An  acquisition  action 
officer  should  liaise  continuously  with  these  units  and  users  to  maintain 
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awareness  of  how  or  if  the  operators  use  the  system.  All  too  often,  a  PMO 
delivers  a  new  system  and  provides  initial  operator  training  without  ever 
attempting  to  learn  from  user  experiences.  Unadulterated  user  input  during  this 
introduction  to  the  system  can  provide  invaluable  insight  into  areas  worthy  of 
potential  improvement.  Often  the  PMO  wrongly  holds  an  attitude  of  finality,  and 
responds  to  user  recommendations  by  saying,  “The  system  is  what  it  is  and  it’s 
not  going  to  change  until  the  next  increment  five  years  from  now.”  This 
unfortunate  outlook  promotes  further  customer  dissatisfaction  and  gives  meaning 
to  cynical  phrases  such  as  drive-by  fielding. 

Opportunities  exist  beyond  the  initial  fielding  to  gather  user  input  as 
well.  The  operational  unit  accepting  a  new  system  will  most  likely  be  actively 
training  or  engaged  in  combat  operations,  either  of  which  makes  an  ideal  test 
bed  for  a  newly  delivered  product.  Action  officers  should  make  every  effort  to 
attend  any  training  exercise  utilizing  a  new  system  to  capture  any  user 
recommendations  and  ideas  for  improvement,  or  just  to  gather  opinions  of  the 
value  the  system  offers.  A  unit  in  combat  will  not  be  as  readily  accessible  as  in 
training,  but  action  officers  should  make  and  maintain  contact  with  the  system 
users  to  gather  valuable  operational  insight  which  serves  to  guide  subsequent 
improvements.  Also,  action  officers  should  strive  to  meet  with  units  returning 
from  operational  deployments  as  soon  after  their  return  as  possible.  Time 
quickly  fades  memories,  both  good  and  bad,  and  a  program  office  must  quickly 
capture  any  lessons  learned  relating  to  the  system. 

Additionally,  acquisition  officers  must  maintain  close  ties  to  the 
organization  charged  with  supporting  the  system.  System  support  can  include 
follow  on  training,  software  patches,  troubleshooting,  help  desk  support,  etc. 
Contractors  or  another  government  office  such  as  the  Marine  Corps  Tactical 
Systems  Support  Activity  will  likely  accomplish  these  tasks  which  should  include 
analysis  of  any  trends  observed  in  support  of  the  system.  This  analysis  can 
indicate  areas  implicitly  needing  improvement  and  can  feed  into  requirements  for 
future  increments. 
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All  of  this  gathering  of  information  regarding  an  operational,  fielded 
system  wastes  time  and  effort  unless  the  program  office  applies  it  through  a 
feedback  mechanism  that  fosters  continual  improvement  of  both  the  product  and 
the  process.  One  mechanism  to  accomplish  this  occurs  through  reviews  of 
future  system  increments.  These  reviews  must  make  it  a  point  to  consider  user 
feedback  regarding  previous  increments  and  incorporate  the  most  highly  valued 
recommendations  into  future  requirements.  Such  a  valid  feedback  mechanism 
will  ensure  emphasis  on  value  and  continual  product  improvement,  both  of  which 
will  increase  the  probability  of  future  program  successes. 

The  process  as  well  as  the  product  in  the  Sustainment  phase 
deserves  attention  in  order  to  remain  relevant  and  correctly  focused.  To  insure 
the  continued  quality  of  the  process,  an  action  officer  must  make  an  honest, 
introspective  analysis  of  the  acquisition  process.  Some  of  the  obvious  questions 
to  ask  in  order  to  follow  the  principles  of  RVEA  are: 

•  Rapid:  Was  the  process  rapid  enough  to  provide  value  to  the  user, 
and  do  future  increments  meet  the  user’s  required  timeline? 

•  Value-based:  Did  the  system  improve  the  user’s  job,  e.g.,  does  the 
user  value  it? 

•  Evolutionary:  Does  the  system  readily  support  upgrades  and 
changes? 

The  more  revealing  questions  of,  “Why?”  or,  “Why  not?”  must  follow 
these  types  of  yes/no  questions.  Reflecting  back  to  the  discussion  of  Boyd’s 
OODA  Loop,  this  analysis  essentially  accomplishes  the  steps  of  observe  and 
orient.  Or  using  Dr.  Hayes-Roth’s  more  detailed  efficient  thought  model 
(reference  Figure  4.  ),  they  equate  to  observing  and  assessing  the  situation. 
The  decision  loops  must  not  stop  there  though.  To  ensure  effectiveness,  action 
officers  must  close  the  loop  by  deciding  upon  desired  changes;  predicting 
outcomes;  and  selecting,  communicating  and  implementing  the  best  plan  of 
action.  Furthermore,  until  the  organization  either  phases  out  or  replaces  the 
system,  it  must  repeat  and  continually  validate  this  cycle  in  rapid  succession. 
Not  doing  so  risks  being  overcome  by  the  enemy  of  obsolescence  and 
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requirements  change,  eventually  resulting  in  decreased  system  value  and 
potential  program  failure.  Such  honest  self-evaluation  of  the  effectiveness  of  the 
acquisition  process  will  enable  a  PMO  to  improve  its  acquisition  process  model 
which  will  produce  more  viable  results  in  the  form  of  increased  user  value. 

Many  may  believe  the  Sustainment  phase  comprises  the  last  of  the 
acquisition  phases  and  as  such,  a  program  office  may  choose  to  coast  through 
system  deployment  and  support  with  minimal  emphasis  on  the  principles  of 
RVEA.  In  fact  though,  this  phase  offers  great  opportunities  to  refocus  on  rapidly 
providing  the  warfighter  valued  products,  increasing  the  validity  of  future 
requirements,  and  improving  the  acquisition  process.  RVEA  prescribes  those 
very  actions,  emphasizing  the  fact  that  acquisition  continues  as  more  of  a 
continuous  cycle  or  loop  than  a  process  with  a  beginning  and  end.  Missing 
opportunities  for  improvement  in  the  Sustainment  phase  because  of  lackadaisical 
system  support  or  an  end-in-sight  PMO  attitude  not  only  does  a  disservice  to  the 
warfighters,  it  potentially  contributes  to  the  demise  of  a  once  viable  program. 

The  table  below  summarizes  this  discussion  on  the  foundation  and 
operation  of  RVEA.  Following  these  acquisition  rules  of  the  road  will  help  ensure 
rapid  and  improving  value  to  the  warfighter...  measurable  program  success. 
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DO 

DO  NOT 

Identify  &  prioritize  required  and  related 
attributes  and  functions.  Priority  should  be 
based  on  value  and  time-to-build  (difficulty) 

Bite  off  on  too  much  functionality  at  once 

Measure  availability  of  valued  information 
(Aiv)  of  each  function  or  service 

Allow  a  vendor  to  lock  the  acquisition  into  a 
proprietary  or  inflexible  product/process 

Make  noticeable  improvements  in  the 
warfighter’s  job...  if  not  possible  initially, 
then  make  the  system  implementation  as 
transparent  as  possible  to  the  user 

Decrease  the  value  of  the  system  by 
unnecessarily  taxing  the  user’s  resources 
(time,  weight,  etc.) 

Inject  military  specific  requirements  into 
developing  COTS  technologies  and  focus 
on  COTS  solutions  as  much  as  possible 

Prolong  service  delivery  by  implementing 
serial  development  of  successive  functions 
before  providing  anything  to  users 

Develop  services  in  parallel,  but  start  with 
those  that  offer  the  biggest  bang  for  the 
buck,  and  work  your  way  down  the 
prioritized  list 

Stop  looking  for  improvements  once  the 
system  passes  OT&E  and  begins  fielding 

Maintain  awareness  of  and  inject  military 
requirements/raw  technology  into  COTS 
developments 

Make  the  users  learn  a  new  system 
without  providing  them  value 

Provide  something  of  value  to  the  user  in 
less  than  2  years  after  deciding  upon  a 
technology 

Transition  the  technology  to  an  acquisition 
program  of  record  until  it’s  mature 

Continuously  look  for  ways  to  improve  not 
only  the  product,  but  the  process 

Assume  the  current  acquisition  system  is 
too  constraining  or  restrictive  for  RVEA 

Design  the  system  for  evolvability 

Be  satisfied  with  the  status  quo 

Table  2.  Dos  and  Don’ts  of  RVEA 


D.  RVEA  OF  A  USMC  TACTICAL  SERVICE  ORIENTED  ARCHITECTURE 

Service  oriented  architectures  have  emerged  as  one  of  the  various 
technical  paradigms  with  great  potential  to  help  attain  the  goals  for  information 
sharing  described  in  our  national  strategies  (Lewis  &  Smith,  2007).  Enterprise 
SOAs  have  benefited  business  entities  in  the  private  sector  and,  if  successfully 
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acquired,  SOA  can  also  benefit  the  DoD  at  not  only  the  enterprise  level  of  the 
military  (DoDD  8320.02,  2004),  but  also  the  tactical  level  of  warfighting. 

1.  What  is  SOA? 

Referencing  Figure  7  below,  a  generic  SOA  is  a  collection  of  services  with 
well-defined  interfaces  and  a  standard  shared  communications  model.  A  service 
usually  exists  as  a  discoverable,  self-contained  software  entity  that  interacts  with 
applications  and  other  services  through  a  loosely  coupled  message-based 
communication  model.  A  service  registry  enables  the  discoverability  of  the 
entities  that  form  services.  Services  exist  as  legacy  or  new  software,  and 
systems  or  users  subscribe  to  the  functionality  provided  by  these  services  to 
achieve  their  purposes.  For  example,  when  a  service  consumer  makes  a 
reservation  through  a  travel  agency  website,  what  appears  as  a  single  web- 
based  application  actually  involves  the  complex  orchestration  of  a  set  of  services 
from  various  providers.  These  services  could  include  user  authentication,  flight 
scheduling,  hotel/rental  car  searches,  reservations  and  credit  card  validation. 
Through  services,  SOAs  offer  the  ideal  of  enabling  legacy  systems  to 
interoperate,  presumably  without  making  significant  changes  (Lewis,  Morris,  & 
Smith,  2005). 
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Figure  7.  Generic  Service  Oriented  Architecture  (Lau,  2007) 

This  section  will  first  point  out  some  of  the  specific  benefits  espoused  by 
SOA  promoters  and  then  make  recommendations  for  applying  the  principles  of 
RVEA  to  the  acquisition  of  a  Tactical  SOA  for  the  USMC. 

Note  the  purpose  of  this  section  is  not  to  wave  a  SOA  flag,  per  se;  rather  it 
uses  TSOA  to  illustrate  a  means  to  better  manage  the  IT  acquisition  process 
through  RVEA.  IT  investments  should  align  with  the  principles  of  RVEA,  and  if  a 
particular  proposed  technology  contradicts  these  principles,  the  acquisition 
should  consider  another  direction.  For  example,  if  one  technology  insists  on 
keeping  its  proprietary  nature  and  as  a  result  does  not  offer  sufficient  flexibility  to 
meet  the  demands  for  continual  improvement,  the  program  should  investigate 
another  possibility.  Service  oriented  architectures  run  counter  to  such  negative 
attributes  as  they  lend  themselves  to  natural  developmental  increments  and 
openness  while  offering  increasing  capabilities  in  their  services.  A  USMC  TSOA 
acquisition  program  therefore  appears  more  than  suitable  for  the  application  of 
RVEA  principles. 
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2. 


Benefits  of  a  Tactical  SOA 


SOA  offers  many  potential  benefits  to  military  applications,  but  perhaps 
none  entice  the  DoD  more  than  the  prospective  cost  savings  and  technological 
agility,  made  possible  due  to  the  inherent  reusability,  flexibility  and  evolvability  of 
SOA  through  vendor-neutral,  open  standards.  Thomas  Erl,  acclaimed  for  his 
expertise  on  the  SOA  and  the  subject’s  best-selling  author  (ThomasErl.com, 
2009),  articulates  other  positives  of  contemporary  SOA: 

Service  orientation  presents  an  ideal  vision  of  a  world  in  which 
resources  are  cleanly  partitioned  and  consistently  represented. 

When  applied  to  IT  architecture,  service-orientation  establishes  a 
universal  model  in  which  automation  logic  and  even  business  logic 
conform  to  this  vision.  This  model  applies  equally  to  a  task,  a 
solution,  an  enterprise,  a  community,  and  beyond.... 

The  service-orientation  ideal  has  sparked  a  movement  that  has 
positioned  SOA  as  the  next  phase  in  the  evolution  of  business 
automation.  In  the  same  manner  in  which  mainframe  systems  were 
succeeded  by  client-server  applications,  and  client-server 
environments  then  evolved  into  distributed  solutions  based  on  Web 
technologies,  the  contemporary,  Web  services-driven  SOA  is 
succeeding  traditional  distributed  architecture  on  a  global  scale. 

All  major  software  manufacturers  and  vendors  are  promoting 
support  for  SOA  -  some  even  through  direct  involvement  in  the 
development  of  open  standards.  As  a  result,  every  major 
development  platform  now  officially  supports  the  creation  of 
service-oriented  solutions.  It  would  appear  as  though  the 
realization  of  the  SOA  ideal  is  well  underway.  (Erl,  2005,  pp.  3-4) 

Table  3  lists  some  of  the  many  benefits  ascribed  to  SOA.  Notice  a  few  of 
these  benefits  appear  performance-oriented,  but  the  majority  of  them  relate  to 
the  architecture’s  inherent  flexibility:  open,  composable,  agile,  reusable,  etc. 
SOA  does  not  lock  the  implementer  into  a  proprietary  stovepipe,  and  it  provides  a 
sufficiently  open  model  for  disparate  architectures  to  federate  more  quickly  and 
usefully  than  earlier  approaches.  These  characteristics  of  SOA  and  its  popularity 
in  the  private  sector  indicate  the  increasing  value  organizations  place  on 
adaptability. 
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TSOA  Benefits 

Contemporary  SOA  Benefits 

(Office  of  Naval  Research,  2008) 

(Erl,  2005) 

• 

Enables  speed  and  flexibility  to 

•  Increases  quality  of  service 

capitalize  on  new  technology  and 
business  arrangements 

•  Based  on  open  standards 

• 

Reduces  time  spent  to  effect 

•  Fosters  intrinsic  interoperability 

changes 

•  Promotes  architectural 

• 

Provides  the  ability  to  leverage 

composability 

existing  technology  investments 

•  Is  fundamentally  autonomous 

• 

Minimizes  the  expense  and 

•  Supports  vendor  diversity 

complexity  of  integration 

•  Promotes  organizational  agility 

• 

Increases  reuse 

•  Fosters  inherent  reusability 

• 

Increases  tactical  agility 

Table  3.  Benefits  of  SOA 


3.  Rapid,  Value-Based,  Evolutionary  Acquisition  of  a  TSOA 

Since  government  acquisitions  cannot  realistically  hope  to  “catch  up”  to 
the  innovations  of  the  private  sector,  the  DoD  must  leverage  the  current  state  of 
the  art  including  developments  such  as  SOA  to  the  best  of  its  ability.  Case  in 
point,  the  enemy  in  the  Global  War  on  Terror  performs  netcentric  command  and 
control  via  modern  mapping,  imaging,  discovery,  and  messaging  services  (etc.) 
available  via  the  World  Wide  Web.  Before  the  documented  SOA  benefits  will 
ever  materialize  in  the  Defense  Department,  acquisition  of  a  TSOA  requires  an 
improved  process  that  concentrates  on  leveraging  externally  produced  value. 
The  current  acquisition  process,  which  often  fails  to  provide  anything  of  value  to 
the  warfighter,  is  causing  justifiable  apprehension  as  the  USMC  investigates 
acquisition  of  a  TSOA.  The  Marines’  efforts  to  date  toward  TSOA  include  a 
feasibility  study  conducted  by  the  Office  of  Naval  Research  (ONR),  part  of  which 
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included  a  draft  technical  description  (TD)  of  the  system10  (Office  of  Naval 
Research,  2008).  This  document,  although  a  draft,  is  thorough  and  continually 
referenced  in  this  section.  As  an  added  benefit,  it  provides  valuable  insight  into 
the  details  of  TSOA  development.  Combining  the  sound  technical 
recommendations  of  the  TD  with  the  principles  of  RVEA — rapid,  value-based, 
and  continual  improvement  through  an  evolutionary  loop — will  increase  the 
chances  of  the  USMC  ultimately  realizing  the  benefits  SOA  offers. 

a.  Realizing  TSOA ’s  Potential  Value 

SOA  adds  value  to  commercial  enterprises  as  pointed  out  in  the 
benefits  listed  above,  but  to  narrow  the  focus  this  section  discusses  how  to 
realize  the  potential  value  of  Tactical  SOA.  The  tactical  aspect  of  TSOA  involves 
making  information  services  available  to  the  lowest  tactical  level  possible,  or  the 
organizational  edge  as  described  by  the  private  sector.  The  warfighter  or  edge 
users  of  TSOA  will  sense  its  value  initially  through  improvements  in  their  ability  to 
perform  currently  existing  tasks.  More  importantly  though,  TSOA  will  help 
promote  future  gains  in  value  through  its  inherent  evolvability...  assuming  an 
acquisition  process  that  concentrates  on  continual  improvement. 

Depending  on  the  first  services  deployed,  TSOA  will  probably  not 
provide  any  apparently  new  or  revolutionary  functionality,  but  it  will  allow  the 
users  to  do  their  job  more  efficiently  and  effectively  because  of  easier  access  to 
and  potential  filtering  of  information.  Networks  supporting  the  tactical  edge  must 
address  two  daunting  challenges:  the  operators  require  great  mobility  while,  at 
the  same  time,  they  must  operate  with  very  limited  communications  bandwidth 
TSOA  must  therefore  embrace  concepts  such  as  Valued  Information  at  the  Right 
Time  (VIRT)  to  insure  against  dreaded  info-glut  and  a  potentially  gridlocked 
network  (Hayes-Roth,  2005).  TSOA,  once  deployed,  will  reduce  the  number  of 


10  The  analysis  performed  for  the  TD  was  part  of  the  Advance  Fires  Coordination 
Technology,  Future  Naval  Capability  program,  which  was  sponsored  by  the  Office  of  Naval 
Research  (ONR)  under  the  technical  direction  of  the  Naval  Surface  Warfare  Center,  Crane  IN. 
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specialized  systems  requiring  their  own  hardware,  which  will  reduce  weight  and 
power  consumption.  Additionally,  the  architecture  will  provide  an  open 
framework  upon  which  future  technologies  and  services  can  build. 

After  initial  implementation  and  establishment  of  the  underlying 
framework,  TSOA  will  evolve,  incorporating  services  which  will  combine  to 
provide  the  same  apparent  functionality  as  current  stovepipe  tactical  applications. 
Unlike  the  legacy  applications  though,  TSOA  will  ideally  enable  information 
sharing  through  semantic  interoperability  between  the  services  comprising  the 
tactical  applications.  Describing  TSOA’s  desired  end  state,  it  will  eventually 
hosts  interoperable  services  for  most  if  not  all  of  the  USMC  warfighting  functions 
of  fires,  maneuver,  intelligence,  command  and  control,  logistics,  and  force 
protection. 

To  better  illustrate  this  notion,  Table  4  lists  some  current  tactical 
applications,  most  of  which  vary  greatly  in  levels  of  complexity  and  functionality. 
TLDHS  and  PFED,  for  example,  have  fairly  limited  application  compared  to  the 
large  and  complex  TBMCS.  Each  of  these  applications  would  subscribe  to 
multiple  distinct  yet  reusable  services  residing  on  a  TSOA.  A  particular  legacy 
application’s  functionality  and  complexity  would  determine  not  only  how  many 
and  which  services  comprise  the  application,  but  also  their  level  of  reusability 
between  applications.  For  instance,  PFED,  AFATDS,  NFCS  and  TLDHS  share 
some  requirements  as  target  entry  devices/applications  for  the  fires  chain.  Each 
could  therefore  potentially  share  a  common  ‘target  recording’  service  since  each 
system  would  utilize  common  target  attributes  such  as  location  and  elevation. 
However,  each  application  would  require  a  unique  ‘fires  request’  service  because 
the  different  firing  platforms  of  artillery,  CAS  aircraft,  and  naval  gun  fire  (NGF)  all 
have  different  request  formats.  This  illustrates  the  concept  of  common,  reusable 
services  bundled  together  with  unique  services  to  provide  tactical  application 
functionality. 


62 


Advanced  Field  Artillery  Tactical  Data  System  (AFATDS) 

Command  and  Control  Personal  Computer  (C2PC) 

Joint  Automated  Deep  Operations  Coordination  System  (JADOCS) 

Mobile  Electronic  Warfare  Support  System  (MEWSS) 

Naval  Fire  Control  System  (NFCS) 

Pocket-Sized  Forward  Entry  Device  (PFED) 

Target  Location,  Designation,  and  Hand  off  System  (TLDHS) 

Theater  Battle  Management  Core  Systems  (TBMCS) 

Web-Enabled  Execution  Management  Capability  (WEEMC) 

Table  4.  Some  Tactical  USMC  Applications 

Although  the  TD  does  not  imply  that  the  fires  chain  should  take  first 
precedence  for  inclusion  in  a  TSOA,  it  studies  fires  as  an  example  because  of  its 
stringent  requirements  for  timeliness,  correctness,  and  conciseness.  Incidentally, 
because  of  these  attributes  and  its  complexity,  the  fires  chain  is  also  probably 
one  of  the  most  difficult  warfighting  functions  to  successfully  develop  and  host  on 
a  TSOA.  The  program  officers,  developers,  and  users  should  prioritize  all 
required  services  in  terms  of  not  only  user  value  but  also  technical  difficulty  and 
implement  the  ones  that  provide  the  most  value  with  the  least  amount  of 
difficulty — the  so-called  low-hanging  fruit.  After  providing  rapid  initial  value,  the 
acquisition  process  must  build  upon  this  success  to  develop  increasingly  difficult 
or  somewhat  less  valued  services.  To  reiterate  the  principles  of  RVEA,  the  TSOA 
acquisition  must  not  attempt  to  provide  too  much  functionality  in  a  single  step,  but 
instead  should  focus  on  rapid  iterations  of  valued  improvements. 

The  TD  appropriately  recommends  both  operational  and  technical 
metrics,  including  latency,  reliability,  interoperability,  and  flexibility,  among  others. 
However,  one  measure  of  value  the  TD  overlooked  includes  a  metric  of 
information  value,  such  as  the  aforementioned  AjV,  which  compares  the  number 
of  bits  that  actually  provide  value  to  the  total  bits  transmitted.  For  instance,  in  the 
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fires  chain  such  valued  information  includes  the  bits  that  positively  contribute  to 
ultimate  target  prosecution,  such  as  those  defining  a  target’s  location,  elevation, 
etc.  This  illustrates  the  fact  that  a  service’s  value  comes  from  (1)  delivering 
information  that  enhances  the  warfighter’s  mission  accomplishment,  and  (2) 
avoiding  distracting  the  warfighter  with  insignificant  information.  TSOA  must 
measure  and  guarantee  value  of  the  information  flowing  over  the  network  using 
metrics  such  as  Aiv. 

The  commercial  IT  market  has  much  to  offer  the  DoD; 
unfortunately,  however,  most  COTS  technologies  do  not  meet  some  of  the  most 
stringent  government  requirements  for  Information  Assurance,  with  respect  to 
authentication,  non-repudiation,  confidentiality,  integrity,  or  information  availability 
(DoDI  8500.2,  2003).  The  TD  points  out  that  SOA  technology  is  not  at  the  level 
of  maturity  required  for  a  simple  COTS  purchase  of  a  Tactical  SOA.  It  outlines 
three  options  for  increasing  the  maturity  of  TSOA  and  then  recommends  one 
option  in  which  the  USMC  takes  the  lead  in  adapting  enterprise  SOA  to  create 
TSOA.  Another  viable  option  for  developing  and  steering  COTS  technologies 
being  studied  by  the  W2COG  smartly  leverages  the  commercial  market  to  better 
address  specific  military  and  government  requirements.  This  option  explores  an 
hypothesis  which  states  that  if  the  government 

(1)  continuously  develops  and  furnishes  critical  raw  technology  to 
the  industrial  base;  and  (2)  simply  publishes  its  use  cases, 
objective  selection  criteria,  and  COTS  competitive  procurement 
budget  in  lieu  of  formal  Engineering  Development  Model-type 
solicitations;  then  continuing  industrial  competition  will  generate 
pure  COTS  offerings  that  are  ever  more  aligned  with  government 
requirements.  (Gunderson  &  Minton,  2009) 
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Raw  technology  in  the  case  of  a  2008  W2COG  demonstration11  included  security 
services  such  as  authentication  and  authorization  for  web  services.  After  the 
interoperability  trial,  the  W2COG  exhibited  the  viability  of  the  above  hypothesis 
by  demonstrating  the  streamlined  procurement  of  a  substantial  and  supportable 
network  capability  upgrade.  This  same  approach  deserves  application  in 
conjunction  with  RVEA  to  the  acquisition  of  TSOA  to  enable  additional  value. 

b.  Rapidity  and  TSOA 

To  avoid  a  prolonged  development  period  that  risks  being 
superseded  by  changing  requirements  and  technology  obsolescence,  TSOA 
should  not  transition  to  an  acquisition  program  of  record  now,  considering  its  low 
level  of  maturity.  Instead,  it  should  remain  under  the  cognizance  of  S&T 
organizations  such  as  ONR  while  the  Marine  Corps  and  other  interested  entities 
inject  their  requirements  into  the  maturation  process. 

Furthermore,  as  mentioned,  the  tactical  edge  involves  operations 
using  limited  bandwidth.  Much  of  a  TSOA’s  connectivity  depends  on  overcoming 
or  adapting  to  this  limitation  through  related  acquisition  programs  such  as  the 
Joint  Tactical  Radio  System  (JTRS).  JTRS  will  potentially  serve  as  an  enabler 
for  improved  network  operations  including  TSOA,  and  it  will  most  likely  deploy  to 
the  lower  tactical  levels  no  sooner  than  about  2015  (Office  of  Naval  Research, 
2008).  The  TSOA  effort  should  synchronize  with  these  enabling  technologies 
and  ensure  sufficient  preparation  to  establish  its  underlying  framework  along  with 
basic  valued  services  upon  their  deployment.  This  does  not  imply  that  TSOA 
should  wait  for  JTRS  fielding,  rather  that  TSOA  should  continue  to  develop  in 
parallel  with  its  enabling  technologies.  Parallel  development  would  require 
increased  agility  such  as  through  building  on  a  commercial  communication  suite 
comparable  to  JTRS  while  planning  for  eventual  transition  to  a  tactical  system. 

11  Coalition  Warrior  Interoperability  Demonstration  2008,  Interoperability  Trial  (IT)  #5.64 
“Trusted  Enterprise  Service  Bus”  (T-ESB)  demonstrates  a  potentially  quantum  improvement  in 
the  government  procurement  model  for  information  systems.  Joint  Interoperability  Test  Command 
(JITC)  sponsored  the  World  Wide  Consortium  for  the  Grid  (W2COG)  Institute  (Wl)  to  conduct  IT 
5.64. 
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Once  realized,  the  basic  TSOA  should  develop  and  incorporate  additional  tactical 
services  rapidly,  continuously  capitalizing  on  lessons  learned  from  previously 
deployed  services  to  expand  its  capability  and  value.  Throughout  this  iterative 
process,  the  Marine  Corps  must  maintain  keen  awareness  of  developments  in 
the  SOA  industry  as  well  as  the  military’s  S&T  centers.  Additionally,  as 
mentioned  above,  the  program  office  must  constantly  evaluate  and  prioritize 
candidate  tactical  services  based  upon  their  value  and  difficulty.  This  process  of 
reassessing  and  retargeting  against  a  moving  target  will  help  ensure  rapid 
delivery  of  TSOA  value. 

Although  realization  of  TSOA  in  six  years  does  not  seem  “rapid,” 
this  recommendation  is  consistent  with  the  principles  of  RVEA.  Considering  the 
rate  of  change  of  technology,  six  years  equates  to  about  three  technology 
generations,  during  which  new  discoveries  and  innovations  will  occur  and 
requirements  will  change.  The  USMC  should  allow  technologies  to  go  where 
they  may  and  attempt  to  steer  or  leverage  their  direction  by  feeding  military- 
specific  requirements  and  interests  to  industry,  instead  of  setting  its  sights  on  a 
target  six  years  in  the  future.  Additionally,  the  USMC  must  consider  the  schedule 
risks  of  TSOA’s  enabling  technologies,  such  as  JTRS,  that  do  not  necessarily 
subscribe  to  RVEA  principles.  Any  slippage  of  one  of  these  programs  induces  a 
proportional  delay  in  TSOA. 

c.  Continual  Improvement  of  TSOA 

TSOA  and  its  associated  acquisition  program  intuitively  support 
continual  improvement  because  of  a  natural  divisibility  into  incremental  service 
acquisitions.  Additionally,  the  architecture’s  inherent  beneficial  attributes  such  as 
reusability  and  modularity  could  logically  play  a  part  in  the  program’s  efforts 
toward  improvement.  One  could  even  say  SOA  helps  enable  continual 
improvement  because  of  its  intended  basis  on  open  standards  that  (1)  do  not 
lock  the  DoD  customer  into  a  single,  proprietary  solution,  and  (2)  offer  flexibility  to 
change  vendors  midstream  if  the  acquisition  process  requires  it.  However,  these 
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benefits  will  not  happen  automatically  and  without  effort  from  those  in  charge. 
The  program  office  must  continue  to  focus  on  the  principles  of  RVEA  in  order  to 
realize  the  benefits  of  TSOA. 

Continual  improvement  of  a  TSOA  product  requires  rapid  iterations 
of  increasingly  valued  capabilities.  The  underlying  open  framework  of  TSOA  will 
not  provide  immediate  value  to  the  user  by  itself.  TSOA’s  value  will  come  from 
the  valued  services  developed  for  and  available  to  the  warfighter,  which  reside 
on  the  framework.  For  example,  the  basic  functionality  of  TSOA  must  include 
authentication  and  authorization  services  with  the  implementation  of  the 
framework.  But  TSOA  and  these  services  alone  provide  no  apparent  functional 
value  for  an  operator.  Instead,  the  value  will  arrive  in  the  form  of  useful 
operational  services  discoverable  to  the  operator.  For  this  reason,  the  value  of 
TSOA  hinges  on  the  rapid  development,  implementation  and  continual 
improvement  of  tactical  services  residing  on  the  underlying  framework. 

A  PMO  must  consistently  evaluate  its  internal  processes  and 
feedback  mechanisms  to  help  guarantee  continual  improvement  of  the  TSOA 
acquisition  process.  The  program  office  must  keep  a  finger  on  the  pulse  of 
COTS  IT  to  ensure  continued  awareness  of  commercial  best 
practices/technologies.  Likewise,  the  government  must  also  inform  the 
commercial  IT  industry  of  government  interests,  requirements  and  raw 
technologies.  Such  shared  awareness  will  allow  government  IT  acquisition  to 
better  leverage  the  COTS  IT  vector  which  will  ultimately  increase  the  supply  of 
potentially  viable  products  and  TSOA  services  to  meet  tactical  military  needs. 
These  efforts  will  help  a  TSOA  program  effectively  keep  up  with  Moore’s  Law 
instead  of  being  beaten  by  it.  The  USMC  and  DoD  must  manage  IT  acquisition, 
especially  COTS,  in  such  a  manner  as  to  enable  and  not  hinder  its  tactical 
objectives,  to  include  information  superiority  to  the  tactical  edge  through  TSOA. 

As  the  last  point  for  continual  improvement  during  TSOA’s 

acquisition,  the  USMC  must  not  put  all  of  its  proverbial  eggs  in  a  single  TSOA 

basket,  inextricably  tying  itself  to  a  technology  that  could  end  up  dying  on  the 
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vine.  Future  innovations  may  lie  right  around  the  corner  and  could  render  SOA 
obsolete  in  its  attempt  to  reach  the  tactical  edge.  A  TSOA  acquisition  program 
must  be  ready,  willing  and  able  to  retarget  on  a  new  technology  if  necessary. 
Staying  in  touch  with  commercial  developments  means  maintaining  an 
awareness  of  not  only  the  world  of  SOA,  but  also  any  other  potential  COTS 
solutions  that  could  benefit  the  organizational  edge.  Technologies  or  protocols 
just  beyond  the  near  future  of  IPv6  and  fourth  generation  wireless  could 
potentially  leave  SOA  obsolete  by  providing  superior  remote,  edge  access  to 
network  services  and  functions.  Program  offices  must  write  acquisition  strategies 
and  their  associated  contracts  in  a  manner  to  allow  such  direction  change,  and 
RVEA  demands  short  cycle  times  to  allow  continual  improvement  and  refocusing 
on  not-so-distant  targets.  A  new  target  could  mean  writing  off  TSOA  sunk  costs 
and  killing  the  program  if  it  would  benefit  the  warfighter.  After  all,  sometimes 
benefit  comes  in  the  form  of  not  fielding  a  new  system. 
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IV.  SUMMARY 


A.  CONCLUSION 

Cost  overruns,  schedule  delays,  and  performance  shortfalls  have  plagued 
defense  IT  acquisition  projects  since  the  acronym  IT  came  into  existence,  and 
they  continue  to  do  so  today.  One  can  attribute  at  least  part  of  this  crisis  to  a 
lack  of  a  clear  definition  of  program  success.  In  its  most  simple  form,  program 
success  means  providing  the  customers  something  they  value;  likewise, 
providing  no  value  to  users  signals  program  failure.  Even  though  they  have 
worthy  intent,  without  such  a  clearly  defined  goal,  acquisition  commands  will 
continue  to  deliver  users  their  best  attempt  at  a  solution  and  often  still  fail  to 
satisfy  operational  needs.  General  blame  for  such  failure  traces  back  to  either  a 
shortfall  of  the  system  itself  or  a  lack  of  timeliness  of  acquisition  and  fielding.  A 
late  system  can  easily  mean  an  ineffective  system  that  lacks  user  value  because 
of  requirements  change  or  technology  obsolescence.  These  points  succinctly 
answer  two  of  the  secondary  research  questions  proposed  at  the  beginning  of 
this  thesis:  (1)  What  defines  acquisition  project  success  and  failure,  and  what 
causes  a  project’s  failure?  (2)  How  does  the  concept  of  timeliness  fit  into  the 
equation  for  acquisition  value? 

As  a  potential  solution  to  many  of  these  problems,  RVEA  focuses  on  three 
primary  factors  that  can  help  improve  the  Defense  acquisition  process:  rapidity, 
user-defined  value,  and  continual  improvement  through  system  and  process 
evolution.  These  factors  answer  the  primary  research  question  of  this  thesis: 
What  essential  principles  enable  acquisition  programs  to  deliver  valued 
capabilities  successfully  to  the  warfighter? 

The  value  basis  of  RVEA  stems  from  user  involvement  in  the  acquisition 
process  from  the  cradle  to  the  grave.  In  order  to  provide  value  to  the  IT  system 
user,  or  the  warfighter,  acquisition  programs  must  identify  and  understand 
exactly  what  the  user  values.  Even  though  broad  requirements  trickle  down  from 
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upper-level  DoD  leadership,  a  program  office  must  intimately  understand  user- 
defined  value  through  proactively  seeking  and  maintaining  user  involvement  in 
the  process...  admittedly  not  an  easy  task.  Despite  their  taxing  operational 
commitments,  the  voice  of  the  warfighters  who  will  experience  the  acquisition 
product  hands-on  must  consistently  resound  through  system  design, 
development,  testing,  manufacturing,  fielding,  and  sustainment.  Such 
involvement  ensures  the  system  will  meet  the  users’  expectations  for  not  only  the 
typical  quality  metrics  such  as  usability,  reliability,  and  supportability,  but  also  the 
timeliness  of  the  acquisition.  The  risk  of  not  doing  so  spells  ultimate  program 
failure  due  to  an  irrelevant  and  unvalued  product. 

Rapidity  and  Defense  Acquisition  used  in  the  same  sentence  regrettably 
has  the  ring  of  an  oxymoron.  If  the  DoD  hopes  to  field  relevant,  operationally 
effective  and  suitable  systems,  the  acquisition  process’s  speed  must  increase 
significantly.  The  current  process  often  fields  outdated  products  because  IT — 
and  incidentally  its  associated  obsolescence — pervades  most  systems  charged 
with  supporting  the  USMC’s  six  warfighting  functions.  The  rate  of  obsolescence 
outpaces  the  current  speed  of  acquisitions  partly  due  to  acquisition  programs 
attempting  to  provide  too  much  functionality  in  a  single  step.  Considering  the 
current  pace  of  innovation  and  technological  advancement,  procurements  should 
concentrate  on  selecting  the  least  difficult  and  highest  value  solutions  currently 
available,  which  often  materialize  as  COTS.  The  least  difficult  solution  implies 
one  readily  available,  mature,  and  proven  in  a  relevant  environment  if  at  all 
possible.  Accepting  anything  less  can  easily  lead  to  schedule  delays  resulting 
from  a  prolonged  development  phase...  quite  the  opposite  of  rapid  acquisition, 
and  a  glaring  opportunity  for  the  enemy,  obsolescence.  Warfighters  expect 
current,  useful  technology  and  abhor  outdated  and  consequently  unnecessary 
equipment.  By  focusing  on  rapidity — providing  small  yet  high  value 
improvements  to  the  warfighter  in  rapid  succession — a  program  increases  its 
chances  of  success. 
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The  aspect  of  continual  improvement  in  the  context  of  RVEA  means 
methodically  evaluating  past  accomplishments  and  failures,  both  in  product  and 
process,  and  applying  lessons  learned  from  these  evaluations  to  future  actions. 
This  ongoing  process  requires  rapid  iterations  of  a  recognized,  formal  feedback 
mechanism  using  appropriate  value  metrics,  as  well  as  a  focus  on  quick 
solutions.  Future  solutions  or  targets  should  remain  as  near  in  the  future  as 
possible  since  distant  targets  (requirements)  move  unpredictably  and  often. 
Quantifying  “near”  as  it  relates  to  IT  suggests  delivering  an  improvement  within 
two  years  of  deciding  upon  a  technology.  Continual  improvement  demands 
subsequent  evaluation  of  the  solution’s  results  and  rapid  application  to  not  only 
current  and  future  products,  but  the  processes  of  acquiring  and  supporting  them 
as  well.  Such  rapid,  short  term  retargeting  will  help  decrease  the  number  of 
programs  that  miss  their  mark  due  to  aiming  at  much  too  distant  targets. 
Additionally,  in  order  to  increase  the  number  of  options  available  as  potential 
acquisition  solutions,  the  DoD  must  inject  its  interests,  concerns  and 
requirements  into  the  mainstream  COTS  marketplace.  As  militarily  useful  COTS 
products  become  available,  the  acquisition  process  must  apply  the  process  of 
continual  improvement  to  them,  promoting  and  capitalizing  on  the  ones  that  work 
and  discarding  the  ones  that  do  not. 

A  tactical  service  oriented  architecture  offers  the  USMC  value  in  its 
supposed  flexibility  and  potential  long-term  cost  savings.  Additionally,  once  in 
place,  it  offers  increased  technical  agility  and  decreased  development  time  of 
future  tactical  services  and  applications.  These  attributes  align  with  and 
positively  support  the  principles  of  RVEA,  and  TSOA  is  therefore  well  suited  for 
the  application  of  RVEA. 

Figure  8  provides  a  diagram  to  help  summarize  the  answer  to  the 
remaining  secondary  research  question  of  this  thesis  that  asks  how  the  USMC 
should  exploit  the  principles  of  rapid,  value-based,  evolutionary  acquisition  for  the 
development  and  procurement  of  a  TSOA?  RVEA  and  TSOA’s  acquisition  first 
require  relevant  demonstration  of  the  maturity  and  value  of  the  technology  by  the 
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S&T  community.  This  must  include  proving  the  readiness  of  not  only  the 
underlying  SOA  framework  and  the  most  basic  required  services,  but  also  the 
highest  priority  tactical  service(s)  offering  the  greatest  “bang-for-the-buck.”  Only 
after  successful  demonstration  should  the  technology  then  transition  to  an 
acquisition  program  of  record,  aiming  to  provide  the  highest  value,  least  difficult 
services  to  the  warfighter  in  less  than  two  years.  Once  established  as  an 
acquisition  program,  rapidity  will  help  ensure  victory  over  the  enemies  of 
obsolescence  and  requirements  change.  Throughout  the  process,  the  program 
office  as  well  as  the  S&T  community  must  constantly  engage  user 
representatives  to  ensure  the  requirements,  current  system  design,  and  future 
increments  remain  valid.  Meanwhile,  the  next  iteration  of  the  entire  process 
should  already  be  underway,  focusing  on  improvement  and  having  adjusted  its 
aim  onto  not-so-distant  targets  according  to  the  inputs  of  a  formal,  methodical 
and  continuous  feedback  mechanism  originating  from  user-defined  value.  Such 
an  acquisition  process  would  increase  the  likelihood  of  success  of  most  IT 
acquisition  programs,  especially  a  TSOA.  In  summary,  TSOA  holds  potential 
benefit  for  the  Marine  Corps,  but  only  if  we  develop  and  procure  it  using 
principles  such  as  those  embraced  by  RVEA. 
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B.  RECOMMENDED  FUTURE  RESEARCH 


The  research  for  this  thesis  and  its  subsequent  writing  uncovered  some 
areas  for  future  work  which  might  prove  useful  to  the  DoD. 

1.  PPBES  and  RVEA 

The  DAS  has  undergone  many  changes  over  the  past  two  decades  in 
response  to  the  arrival  of  the  information  age.  The  system  has  adapted  in  an 
attempt  to  meet  the  challenges  associated  with  acquiring  increasingly 
sophisticated  equipment  and  capabilities.  The  PPBE  system,  however,  has  not 
sufficiently  changed  to  meet  these  challenges  and  has  become  a  hindrance  to 
the  progress  of  acquisition.  While  RVEA  stresses  speed,  flexibility  and 
efficiency,  the  PPBES  does  not,  and  the  two  therefore  appear  ill-suited  for  each 
other.  Research  and  recommendations  to  increase  the  PPBES’s  rapidity  and 
responsiveness  for  acquisition  programs  would  greatly  benefit  the  field  of 
Defense  IT  acquisitions.  This,  however,  is  no  small  undertaking  and  would  most 
likely  involve  statutory  and  regulatory  changes.  Assuming  the  federal 
government  will  someday  revamp  the  PPBES,  this  research  could  prove  valuable 
as  a  precursor  to  such  an  effort. 

2.  Cost-Benefit  Analysis  of  USMC  SOA 

Trying  to  capture  quantifiable  costs  and  benefits  presents  difficult 
challenges,  at  best,  in  the  public  domain  where  emphasis  is  not  on  profit. 
Analysts  can  measure  some  costs  directly  but  other  distantly  related  and 
sometimes  expensive  side-effects  evade  even  the  best  cost  analysts.  Benefits 
present  an  even  great  measurement  challenge,  especially  in  the  military,  due  to 
the  fact  that,  for  example,  sometimes  benefit  lies  in  the  number  of  lives  or  limbs 
saved...  a  metric  nearly  impossible  to  apply  a  dollar  figure  to.  A  cost-benefit 
analysis  of  a  USMC  SOA  would  therefore  be  a  challenging,  yet  valuable,  thesis 
opportunity.  Such  an  analysis  could  involve  either  a  TSOA  or  a  more 
administratively  focused  enterprise  SOA.  The  comparison  could  measure  time 

saved  by  the  user,  accuracy  of  data,  and  personnel  metrics,  to  name  a  few. 
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3.  Establishing  a  Formal  Beta-Test  Community 

As  this  thesis  points  out,  user  involvement  in  the  acquisition  process  helps 
define  system  value  and  contributes  to  program  success.  Such  user 
involvement,  though,  is  often  extremely  difficult  and  expensive  to  coordinate  due 
to  the  time-constrained  schedules  of  the  user  community.  Operational 
commitments,  both  in  continental  U.S.  training  and  overseas  combat,  tax  tactical 
system  users  sometimes  to  a  point  of  16+  hour  days,  7  days  a  week.  A  formally 
established  tactical  beta-test  community  of  users  could  help  alleviate  this 
problem.  This  community  could  stand  up  as  a  mini-battalion,  for  example,  with  a 
sampling  of  various  combat  arms  MOSs.  Assignment  to  this  unit  would  require 
the  Marines  to  have  recent  operational  experience  in  their  MOS,  and  they  would 
serve  there  for  a  minimum  of  two  years.  The  unit  would  provide  system  testers 
and  user  representatives  as  dedicated  direct  support  to  the  acquisition 
community.  The  recommended  research  could  investigate  the  feasibility  of 
establishing  such  a  beta-test  unit  and  complete  a  cost-benefit  comparison  on  it. 


74 


BIBLIOGRAPHY 


Alberts,  D.  S.,  Garstka,  J.  J.,  &  Stein,  F.  P.  (1999).  Network  Centric  Warfare  - 
Developing  and  Leveraging  Information  Superiority.  Washington  D.C.: 

DoD  C4ISR  Cooperative  Research  Program. 

Beck,  D.  S.  (2003).  Microelectronics  Obsolescence  Management.  Monterey: 
Naval  Postgraduate  School. 

Boessenkool,  A.  (2009,  March  4).  DoD  IT  Procurement  Too  Slow:  Cartwright  - 
Defense  News.  Retrieved  March  14,  2009,  from  DefenseNews.com: 
http://www.defensenews.com/story.php?i=3975151 

Boyd,  J.  (1986).  Retrieved  April  14,  2009,  from  Defense  and  the  National  Interest 
Web  Site:  http://www.d-n-i.net/bovd/pdf/poc.pdf 

Charette,  R.  N.  (2005,  September).  IEEE  Spectrum:  Why  Software  Fails. 
Retrieved  April  3,  2009,  from  IEEE  Spectrum: 
http://www.spectrum.ieee.org/sep05/1685 

CJCSI  3170.01  F.  (2007,  May  1).  Washington  D.C.:  Chairman  of  the  Joint  Chiefs 
of  Staff,  http://www.dtic.mil/cjcs  directives/cdata/unlimit/3170  01.pdf 

Cleland,  D.  I.,  &  Gareis,  R.  (2006).  Global  Project  Management  Handbook  - 
Planning,  Organizing  and  Controlling  International  Projects.  New  York: 
McGraw-Hill. 

ComputerHistory.org.  (2007).  Retrieved  April  3,  2009,  from  1965  -  "Moore's  Law" 
Predicts  the  Future  of  Integrated  Circuits: 

http://www.computerhistorv.org/semiconductor/timeline/1965-Moore.html 

Cowan,  J.  L.  (2000).  From  Air  Force  Fighter  Pilot  to  Marine  Corps  Warfighting: 
Colonel  John  Boyd,  His  Theories  on  War,  and  their  Unexpected  Legacy. 
Quantico,  VA:  Marine  Corps  University,  http://www.d-n- 
i.net/fcs/boyd  thesis.htm 

Denning,  P.  J.,  Gunderson,  C.  &  Hayes-Roth,  R.  (2008,  December).  Time  to 
Take  Evolutionary  Development  Off  the  Shelf.  Communications  of  the 
ACM  ,  pp.  29-31 .  http://cacm.acm.org/magazines/20Q8/12/3354-time-to- 
take-evolutionary-development-off-the-shelf/fulltext 

DoD  Information  Management  and  Information  Technology  Strategic  Plan. 

(2008-2009).  Washington  D.C.:  DoD  CIO.  http://www.defenselink.mil/cio- 
nii/docs/DoDCIO  Strat  Plan.pdf 


75 


DoDD  8320.02.  (2004).  Data  Sharing  in  a  Net-Centric  Department  of  Defense. 
Washington  D.C.:  ASD(NII)/DoD  CIO. 
http://www.dtic.mil/whs/directives/corres/pdf/832002p.pdf 

DoDI  5000.02.  (2008,  December  2).  Operation  of  the  Defense  Acquisition 
System  .  Washington  D.C.:  USD(AT&L). 
http://www.dtic.mil/whs/directives/corres/pdf/500002p.pdf 

Drucker,  P.  F.  (2001).  The  Essential  Drucker  -  Selections  from  the  Management 
Works  of  Peter  F.  Drucker.  New  York:  HarperCollins  Inc. 

Erl,  T.  (2005).  Service  Oriented  Architecture  -  Concepts,  Technology,  and 
Design.  Upper  Saddle  River,  NJ:  Pearson  Education,  Inc. 

FedBizOpps.gov  (2008,  April).  Retrieved  January  21, 2009,  from  The  Marine 
Corps  Systems  Command  is  requesting  information  concerning  the 
governance,  development,  and  operation  of  Service  Oriented 
Architectures: 

https://www.fbo.  qov/index?s=opportunity&mode=form&tab=core&id=f6044 

1ec0384ac81fccf12076060cd39&  cview=0&cck=1&au=&ck 


Federal  Acquisition  Regulation.  (2005,  March).  Washington  D.C.:  Department  of 
Defense,  http://farsite.hill.af.mil/ 

Field,  T.  (1997,  October  15).  When  bad  things  happen  to  good  projects.  CIO 
Magazine  ,  11,2,  p.  54  (As  reported  by  Frese  &  Stauter  (2003)). 

Frese,  R.,  &  Sauter,  V.  (2003,  December  16).  Project  Success  and  Failure:  What 
Is  Success,  What  Is  Failure,  And  How  Can  You  Improve  Your  Odds  for 
Success?  Retrieved  February  2009,  from 
http://www.umsl.edu/~sauterv/analysis/6840  f03  papers/frese/ 

GAO/HR-99-1.  (1999).  High  Risk  Series:  An  Update  .  Washington  D.C.:  U.S. 
Government  Accountability  Office. 
http://www.qao.gov/archive/1999/hr99001  .pdf 

GAO-06-1 10.  (2006).  Best  Practices:  Better  Support  of  Weapon  System  Program 
Managers  Needed  to  Improve  Outcomes  .  Washington  D.C.:  U.S. 
Government  Accountability  Office. 
http://www.qao.gov/new.items/d061 10.pdf 

GAO-08-1 159T.  (2008).  Fundamental  Changes  Are  Needed  to  Improve  Weapon 
Program  Outcomes  .  Washington  D.C.:  U.S.  Government  Accountability 
Office,  http://www.qao.gov/new.items/d081 1 59t.pdf 


76 


GAO-08-379.  (2008).  Termination  Costs  Are  Generally  Not  a  Compelling  Reason 
to  Continue  Programs  or  Contracts  That  Otherwise  Warrant  Ending  . 
Washington  D.C.:  U.S.  Government  Accountability  Office. 
http://www.qao.gov/new.items/d08379.pdf 

GAO-08-782T.  (2008).  Better  Weapon  Program  Outcomes  Require  Discipline, 
Accountability,  and  Fundamental  Changes  in  the  Acquisition  Environment 
.  Washington  D.C.:  U.S.  Government  Accountability  Office. 
http://www.qao.gov/new.items/d08782t.pdf 

Gunderson,  C.  G.,  &  Minton,  D.  (2009).  CWID  08  Demonstrates  Rapid 
Evolutionary  Acquisition  Model  of  Coalition  C2. 

Gunderson,  C.,  Minton,  D.,  &  Hayes-Roth,  R.  (2009).  Value-Based  Acquisition: 
An  Objective,  Success-Centric,  Evolutionary  Approach. 

Hall,  A.  D.  (1962).  A  Methodology  for  Systems  Engineering.  New  York:  D.  Van 
Nostrand  Co,  Inc. 

Hayes-Roth,  R.  (2006).  Hyper-Beings:  How  Intelligent  Organizations  Attain 
Supremacy  through  Information  Superiority.  Booklocker.com,  Inc. 

Hayes-Roth,  R.  (2005).  Model-based  Communication  Networks  and  VIRT: 

Filtering  Information  by  Value  to  Improve  Collaborative  Decision-Making. 
Monterey:  Naval  Postgraduate  School. 
http://facultv.nps.edu/fahayesr/virt.html 

Hayes-Roth,  R.,  Blais,  C.,  Pullen,  J.  M.,  &  Brutzman,  D.  (2008).  How  to 

Implement  National  Information  Sharing  Strategy:  Detailed  Elements  of 
the  Evolutionary  Management  Approach  Requried.  GMU-AFCEA 
Symposium  on  C4I  Challenges. 

http://faculty.nps.edu/fahavesr/docs/Hayes-Roth%20AFCEA- 

GMU%20lmplementinq%20Sharinq.pdf 

Hoffman,  T.  (2003,  October  27).  Corporate  Execs  Try  New  Ways  to  Align  IT  With 
Business  Units.  Retrieved  February  2009,  from  ComputerWorld.com: 
http://www.computerworld.com/printthis/2003/0,4814,86466,00.html 

Hulme,  M.  (1997).  Procurement  Reform  and  MIS  Project  Success.  Journal  of 
Supply  Chain  Management  -  Winter  1997 , 33  (1 ),  p.  2  (As  reported  by 
Frese  &  Sauter  (2003)). 

Joint  Publication  3-13.  (2006,  February  13).  Information  Operations  .  Washington 
D.C.:  Chairman  of  the  Joint  Chiefs  of  Staff. 
http://www.dtic.mil/doctrine/jel/new  pubs/jp3  13.pdf 


11 


Jones,  C.  (2004).  Software  Project  Management  Practices:  Failure  vs.  Success. 
Crosstalk  -  The  Journal  of  Defense  Software  Engineering  (Oct). 
http://www.stsc.hill.af.mil/crossTalk/2004/10/0410Jones.html 

Jones,  L.  R.,  McCaffery,  J.,  &  Fierstine,  K.  L.  (2005).  Budgeting  for  National 
Defense  Acquisition:  Assessing  System  Linkage  and  the  Impact  of 
Transformation.  Monterey:  United  States  Naval  Postgraduate  School. 

Kozak-Holland,  M.  (2007,  June).  What  Determines  a  Project  Success  or  Failure? 
Retrieved  January  2009,  from  lessons-from-history.com: 
http://www.lessons-from-history.com/Level%202/Proiect%20Success 

Lau,  Y.-T.  (2007,  August).  A  Unified  Service  Description  for  the  Global 

Information  Grid.  Retrieved  May  19,  2009,  from  STSC  Crosstalk  -  The 
Journal  of  Defense  Software  Engineering: 
http://www.stsc.hill.af.mil/crosstalk/2007/08/0708Lau.html 

Lewis,  G.  A.,  &  Smith,  D.  B.  (2007,  September).  Four  Pillars  of  Service  Oriented 
Architecture.  Crosstalk  -  The  Journal  of  Defense  Software  Engineering. 
http://www.stsc.hill.af.mil/crossTalk/2007/09/0709LewisSmith.html 

Lewis,  G.,  Morris,  E.,  &  Smith,  D.  (2005,  October).  Migration  of  Legacy 

Components  to  Service-Oriented  Architectures.  Retrieved  May  19,  2009, 
from  SoftwareTechNews.com/: 

https://www.softwaretechnews.com/stn  view.php?stn  id=1  &article  id=27 

O'Brochta,  M.  (2002,  October  3-10).  Project  Success  -  What  Are  the  Criteria  and 
Whose  Opinion  Counts?  Proceedings  of  the  Project  Management  Institute 
Annual  Seminars  and  Symposiums  .  San  Antonio,  Texas:  As  reported  by 
Frese  and  Sauter  (2003). 

Office  of  Naval  Research.  (2008).  Notional  Marine  Corps  Tactical  SOA  Technical 
Description  -  Enabling  Net-Centric  Warfare  Spanning  the  Tactical  Edge. 
Version  1.2  (Final  Coordination  Draft). 

Robinson,  G.  (2000,  September  26).  Speeding  Net  Traffic  with  Tiny  Mirrors. 
Retrieved  April  3,  2009,  from  EE  Times: 
http://www.eetimes.com/storv/OEG20000926S0Q65 

Sangwan,  R.  S.,  Lin,  L.-P.,  &  Neill,  C.  J.  (2008,  October).  Complexity  in 

Architecture-Centric  Software  Evolution.  Computer  (IEEE Xplore)  ,  pp.  96- 
99. 

Stevenson,  J.  (2001).  The  $5  Billion  Misunderstanding.  Annapolis:  Naval  Institute 
Press. 


78 


Stogdill,  R.  C.  (1999,  April-June).  Dealing  with  Obsolete  Parts.  IEEE  Design  and 
Test  of  Computers ,  16,2,  17-25  (As  reported  by  Beck  (2003)). 

The  National  Defense  Authorization  Act.  (1996).  Washington  D.C.:  104th  U.S. 
Congress.  http://www.nist.gov/director/ocla/Public  Laws/PLI 04-1 06.pdf 

ThomasErl.com.  (2009).  Retrieved  May  11,  2009,  from  Thomas  Erl's  Profile  Site: 
www.thomaserl.com 


Walter,  C.  (2005,  August).  Kryder's  Law.  Retrieved  April  3,  2009,  from  Scientific 
American:  http://www.sciam. com/article. cfm?id=krvders-law 

Young,  J.  J.  (2009,  January  30).  Memorandum  to  OSD.  Reasons  for  Cost 

Changes  for  Selected  Major  Defense  Acquisition  Programs  .  Washington 
D.C. 


79 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


80 


INITIAL  DISTRIBUTION  LIST 


1.  Defense  Technical  Information  Center 
Ft.  Belvoir,  Virginia 

2.  Dudley  Knox  Library 
Naval  Postgraduate  School 
Monterey,  California 

3.  Dan  Boger 

Naval  Postgraduate  School 
Monterey,  California 

4.  Rick  Hayes-Roth 

Naval  Postgraduate  School 
Monterey,  California 

5  Carl  Oros 

Naval  Postgraduate  School 
Monterey,  California 

6.  Vaughn  Pangelinan 
Naval  Postgraduate  School 
Monterey,  California 

7.  Chris  Gunderson 

Naval  Postgraduate  School 
Monterey,  California 

8.  Scott  Bey 

Marine  Corps  Systems  Command 
Quantico,  Virginia 

9.  Basil  Moncrief 

Marine  Corps  Systems  Command 
Quantico,  Virginia 

8.  Tyrone  Ferrel 

Naval  Postgraduate  School 
Monterey,  California 


81 


